JP2018181350A - アプリケーションの保安性を評価する方法およびシステム - Google Patents

Abstract

【課題】アプリケーションの保安性を評価する方法およびシステムを提供する。【解決手段】保安性評価システムは、パッケージファイルを難読化（ｏｂｆｕｓｃａｔｉｏｎ）観点および脆弱性（ｖｕｌｎｅｒａｂｉｌｉｔｙ）観点によって分析するための観点別パターン情報を格納する観点別パターン情報格納部１０１０、アプリケーションのインストールおよび駆動のために利用者に配布するためのパッケージファイルの登録を受けるパッケージファイル登録部１０２０、前記登録されたパッケージファイルを前記観点別パターン情報に基づいて分析し、難読化観点の分析情報および脆弱性観点の分析情報を生成する分析情報生成部１０３０、および前記生成された分析情報を提供する分析情報提供部１０４０を含む。【選択図】図１０

Description

以下の説明は、アプリケーションの保安性を評価する方法およびシステム、コンピュータと結合して保安性評価方法をコンピュータに実行させるためにコンピュータ読取可能な記録媒体に格納されたコンピュータプログラムに関する。

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

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

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

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

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

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

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

アプリケーションパブリッシャの観点において、登録されるアプリケーションに適用された保安水準を難読化（ｏｂｆｕｓｃａｔｉｏｎ）、脆弱性（ｖｕｌｎｅｒａｂｉｌｉｔｙ）、および保安ソリューションそれぞれの観点によって客観的な方法で分析および把握し、分析された情報を提供してアプリケーションの保安性向上のために活用することができる、保安性評価方法およびシステムを提供する。

アンドロイドアプリケーションパッケージ（ＡＰＫ）に含まれるＤｅｘ（Ｄａｌｖｉｋ Ｅｘｅｃｕｔａｂｌｅ）ファイルに対する難読化の適用有無を決定することができる、保安性評価方法およびシステムを提供する。

ＥＬＦ（Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋａｂｌｅ Ｆｏｒｍａｔ）ファイルに対する難読化の適用有無を探知することができる、保安性評価方法およびシステムを提供する。

ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋｉｎｇ Ｌｉｂｒａｒｙ）のようなＰＥ（Ｐｏｒｔａｂｌｅ Ｅｘｅｃｕｔａｂｌｅ）ファイルに対する難読化の適用有無を探知することができる、保安性評価方法およびシステムを提供する。

アプリケーションの保安性を評価する方法であって、パッケージファイルを難読化（ｏｂｆｕｓｃａｔｉｏｎ）観点および脆弱性（ｖｕｌｎｅｒａｂｉｌｉｔｙ）観点によって分析するための観点別パターン情報を格納する段階、アプリケーションのインストールおよび駆動のために利用者に配布するためのパッケージファイルが登録される段階、前記登録されたパッケージファイルを前記観点別パターン情報に基づいて分析し、難読化観点の分析情報および脆弱性観点の分析情報を生成する段階、および前記生成された分析情報を提供する段階を含むことを特徴とする、保安性評価方法を提供する。

アプリケーションの保安性を評価するシステムであって、コンピュータ読取可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、パッケージファイルを難読化観点および脆弱性観点によって分析するための観点別パターン情報を格納し、アプリケーションのインストールおよび駆動のために利用者に配布するためのパッケージファイルが登録され、前記登録されたパッケージファイルを前記観点別パターン情報に基づいて分析し、難読化観点の分析情報および脆弱性観点の分析情報を生成し、前記生成された分析情報を提供することを特徴とする、保安性評価システムを提供する。

前記保安性評価方法をコンピュータに実行させるためのコンピュータプログラムが記録されていることを特徴とする、コンピュータ読取可能な記録媒体を提供する。

コンピュータと結合して前記保安性評価方法をコンピュータに実行させるためにコンピュータ読取可能な記録媒体に格納される、コンピュータプログラムを提供する。

アプリケーションパブリッシャの観点において、登録されるアプリケーションに適用された保安水準を難読化、脆弱性、および／または保安ソリューションそれぞれの観点によって客観的な方法で分析および把握し、分析された情報を提供することにより、アプリケーションの保安性向上のために活用することができる。

アンドロイドアプリケーションパッケージ（ＡＰＫ）が含むＤｅｘファイルに対する難読化の適用有無を決定することができる。

ＥＬＦファイルに対する難読化の適用有無を探知することができる。

ＤＬＬのようなＰＥファイルに対する難読化の適用有無を探知することができる。

本発明の一実施形態における、ネットワーク環境の例を示した図である。 本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。 本発明の一実施形態における、保安性評価システムを示したブロック図である。 本発明の一実施形態における、分析情報の提供のために報告書が含む情報の例を示した図である。 本発明の一実施形態における、脆弱性観点の分析情報の例を示した図である。 本発明の一実施形態における、パースされたｄｌｌファイルが含むクラスとメソッドの例を示した図である。 本発明の一実施形態における、パースされたｄｌｌファイルから識別されるクラスとメソッドを基盤とした難読化観点の分析情報の例を示した図である。 本発明の一実施形態における、パースされたｓｏファイルに対する難読化観点の分析情報の例を示した図である。 本発明の一実施形態における、パースされたｓｏファイルに対する難読化観点の分析情報の他の例を示した図である。 本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第１例を示したブロック図である。 本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第１例を示したフローチャートである。 本発明の一実施形態における、Ｄｅｘ（デックス）ファイルの難読化の適用有無を決定する例を示した図である。 本発明の一実施形態における、ＡＰＩコールの探知過程の例を示した図である。 本発明の一実施形態における、本体命令の暗号化を利用した難読化を探知する例を示した図である。 本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第２例を示したブロック図である。 本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第２例を示したフローチャートである。 本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第３例を示したブロック図である。 本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第３例を示したフローチャートである。 本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルの難読化を探知する第１例を示した図である。 本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルの難読化を探知する第１例を示した図である。 本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルの難読化を探知する第２例を示した図である。 本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルの難読化を探知する第３例を示した図である。 本発明の一実施形態における、ＥＬＦファイルのＥＬＦヘッダに対する難読化を探知する例を示した図である。 本発明の一実施形態における、実行コードを含むセクションのヘッダに対する難読化の適用有無を決定する例を示した図である。 本発明の一実施形態における、コードに対する難読化を探知する例を示した図である。 本発明の一実施形態における、コードの整合性を説明するための例示図である。 本発明の一実施形態における、分岐位置に関する情報に基づいてコードの難読化の適用有無を決定する例を示した図である。 本発明の一実施形態における、ソースコードにダミーコードを追加する例を示した図である。 本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第４例を示したブロック図である。 本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第４例を示したフローチャートである。 本発明の一実施形態における、ＥＬＦヘッダに対する難読化の適用有無を決定する方法を示したフローチャートである。 本発明の一実施形態における、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）のヘッダの難読化の適用有無を決定する方法を示したフローチャートである。 本発明の一実施形態における、実行コードを含むセクションのヘッダに対する難読化の適用有無を決定する方法を示したフローチャートである。 本発明の一実施形態における、動的リンクシンボルテーブルセクションに対する難読化の適用有無を決定する方法を示したフローチャートである。 本発明の一実施形態における、読み取り専用（ｒｅａｄ−ｏｎｌｙ）セクションに対する難読化の適用有無を決定する方法を示したフローチャートである。 本発明の一実施形態における、コードに対する難読化の適用有無を決定する方法の第１例を示したフローチャートである。 本発明の一実施形態における、コードに対する難読化の適用有無を決定する方法の第２例を示したフローチャートである。 本発明の一実施形態における、コードに対する難読化の適用有無を決定する方法の第３例を示したフローチャートである。 本発明の一実施形態における、命令を分析してコードに対する難読化の適用有無を決定する方法を示したフローチャートである。 本発明の一実施形態における、登録されたパッケージファイルが含むＰＥファイルの例を示した図である。 本発明の一実施形態における、全体バイナリが暗号化されたＰＥファイルに対する難読化の適用有無を決定する過程の例を示した図である。 本発明の一実施形態における、特定のクラスや特定のメソッドが暗号化されたＰＥファイルの例を示した図である。 本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第５例を示したブロック図である。 本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第５例を示したフローチャートである。 本発明の一実施形態における、本体命令を抽出する方法の例を示したフローチャートである。 本発明の一実施形態における、ＰＥファイルに対する難読化の適用有無を決定する例を示した図である。

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

本発明の実施形態に係る保安性評価システムは、以下で説明されるサーバによって実現されてよく、本発明の実施形態に係る保安性評価方法は、上述したサーバによって実行されてよい。例えば、サーバには、本発明の一実施形態に係るコンピュータプログラムがインストールされて駆動してよく、サーバは、駆動するコンピュータプログラムの制御に従って本発明の一実施形態に係る保安性評価方法を実行してよい。上述したコンピュータプログラムは、コンピュータで実現されるサーバと結合して保安性評価方法をコンピュータに実行させるためにコンピュータ読取可能な記録媒体に格納されてよい。

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

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

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

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

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

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

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

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

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

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

図３は、本発明の一実施形態における、保安性評価システムを示したブロック図である。図３の保安性評価システム３００は、上述したサーバ１５０によって実現されてよく、保安性評価システム３００に含まれるパッケージ分解モジュール３１０、ファイル識別モジュール３２０、パースモジュール３３０、分析モジュール３４０、およびレポートモジュール３５０は、サーバ１５０のプロセッサ２２２の互いに異なる機能（ｄｉｆｆｅｒｅｎｔ ｆｕｎｃｔｉｏｎｓ）の表現であってよい。

例えば、サーバ１５０のプロセッサ２２２は、コンピュータプログラムに含まれる制御命令に従ってパッケージファイルを分解するプロセッサ２２２の機能として、パッケージ分解モジュール３１０を利用してよい。このとき、分析モジュール３４０に含まれる脆弱性探知モジュール３４２が、脆弱性探知のための核心モジュールとして実現されてよい。

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

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

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

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

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

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

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

分析モジュール３４０は、パースモジュール３３０から伝達される情報に基づき、該当のパッケージファイル（または、該当のパッケージファイルによって電子機器１（１１０）のような利用者端末にインストールされて駆動されるアプリケーション）に対する難読化観点、脆弱性観点、および保安ソリューション観点による分析情報を生成および提供してよい。

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

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

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

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

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

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

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

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

図４は、本発明の一実施形態における、分析情報の提供のために報告書に含まれる情報の例を示した図である。図４は、本発明の理解を助けるための一実施形態に過ぎず、報告書に含まれる分析情報の例や分析情報の伝達方式は、実施形態によって異なってもよい。

例えば、パッケージファイルのファイルフォーマットがアンドロイドではなく他のオペレーティングシステムのためのファイルフォーマットである場合、パッケージファイルに含まれるファイルの情報やその構成方式がファイルフォーマットによって異なってもよいことは、当業者であれば容易に理解することができるであろう。以下で説明するファイル４１０〜４８０は、該当のファイルに含まれる情報を、ユーザに有意に整理して表現するためのテンプレート情報などを含んでもよい。

「Ｒｅｐｏｒｔ．ｈｔｍｌ」ファイル４１０は、対象となるパッケージファイルの全体の脆弱性等級に関する情報と、該当のパッケージファイルに適用された保安ツールに関する情報を含んでよい。

「ＷｉｋｉＲｅｐｏｒｔ．ｈｔｍｌ」ファイル４２０は、パッケージファイルに含まれるモジュール別またはファイル別の難読化等級に関する情報と、難読化に関する他の情報を含んでよい。

「Ｐａｃｋａｇｅｓ．ｈｔｍｌ」ファイル４３０は、パッケージファイルに含まれるファイル（一例として、ｐｌｉｓｔファイル、ｓｏファイル、ｘｍｌファイル、ｊｓｏｎファイルなど）に関する情報を含んでよい。

「Ｐｌａｔｆｒｏｍ．ｈｔｍｌ」ファイル４４０は、ＵｎｉｔｙやＣｏｃｏｓなどのような開発ツールのように、該当のパッケージファイルがどのプラットフォームで開発されたかに関する情報を含んでよい。

「Ｐｅｒｍ．ｈｔｍｌ」ファイル４５０は、アンドロイドパーミッション（Ａｎｄｒｏｉｄ ｐｅｒｍｉｓｓｉｏｎ）使用のリストに関する情報を含んでよい。

「Ｃｏｒｒｅｌａｔｉｏｎ．ｈｔｍｌ」ファイル４６０は、パッケージファイルのモジュール間またはファイル間の呼び出し関係に関する情報を含んでよい。

「ＡｐｐｌｉｅｄＳｅｃｕｒｉｔｙＴｏｏｌ．ｈｔｍｌ」ファイル４７０は、パッケージファイルに適用された保安ツールに関するリスト情報を含んでよい。また、「ＡｐｐｌｉｅｄＳｅｃｕｒｉｔｙＴｏｏｌ．ｈｔｍｌ」ファイル４７０は、適用された保安ツールそれぞれの種類やバージョンに関する情報をさらに含んでもよい。

「ｄｌｌ、ｓｏファイル情報」４８０は、各ファイルに含まれる特定の項目に関する情報を含んでよい。例えば、ｓｏファイルのインポートアドレステーブル（ＩＡＴ）、エクスポートアドレステーブル（ＥＡＴ）、セクションヘッダ（ｓｅｃｔｉｏｎ ｈｅａｄｅｒ）、プログラムヘッダ（Ｐｒｏｇｒａｍ ｈｅａｄｅｒ）、シンボル（ｓｙｍｂｏｌ）などに関する情報が「ｄｌｌ、ｓｏファイル情報」４８０に含まれて提供されてよい。

図５は、本発明の一実施形態における、脆弱性観点の分析情報の例を示した図である。

図５の表５００において、「タイプ（ｔｙｐｅ）」は、該当の項目が脆弱性観点の分析情報であることを示している。また、図５の表５００において、「名称（ｎａｍｅ）」は、どの脆弱性であるかを示す識別子を示している。また、図５の表５００において、「危険等級（ｄａｎｇｅｒｏｕｓ ｇｒａｄｅ）」は、探知された脆弱性の危険等級を示している。さらに、図５の表５００において、「探知ログ（ｄｅｔｅｃｔｅｄ ｌｏｇ）」は、該当の脆弱性が、パッケージファイルが含むファイルのうちのどのファイルから探知されたかを示すために、該当のファイルの識別子（パスを含むファイル名）と脆弱性に関する情報（一例として、どのオープンソースから発見された脆弱性かに関する識別子）を示している。

図６は、本発明の一実施形態における、パースされたｄｌｌファイルに含まれるクラスとメソッドの例を示した図であり、図７は、本発明の一実施形態における、パースされたｄｌｌファイルから識別されたクラスとメソッドを基盤とした難読化観点の分析情報の例を示した図である。

図６の四角ボックス６００は、パッケージファイルが含むｓｏファイルから抽出されたクラス（ｃｌａｓｓ）とメソッド（ｍｅｔｈｏｄ）それぞれの識別情報を示している。一例として、図３を参照しながら説明した難読化探知モジュール３４１は、図６のように抽出されたクラスとメソッドを分析することで、難読化されたクラスと難読化されたメソッドを把握してよい。

このとき、保安性評価システム３００は、図７の表７００のように、難読化観点の分析情報を生成してよい。

図７の表７００において、「名称」は、該当のｄｌｌファイルの識別子を、「危険等級」は、該当のｄｌｌファイルの難読化観点の危険等級を、「探知ログ」は、難読化に関する情報をそれぞれ示してよい。

ここで、図７の表７００において、「ＭｅｔｈｏｄＣｒｙｐｔｅｄ」は、メソッドの難読化の適用有無を示してよく、このとき、「ｙｅｓ」は、メソッドに難読化が適用されていることを示す値であってよい。

また、図７の表７００において、「ＴｏｔａｌＣｌａｓｓＮｕｍ＝２３」は、該当のｄｌｌファイルから抽出されたクラスの数が２３個であることを意味してよく、「ＴｏｔａｌＭｅｔｈｏｄＮｕｍ＝２３」は、該当のｄｌｌファイルから抽出されたメソッドの数が２３個であることを意味してよい。

一方、図７の表７００において、「ＴｏｔａｌＯｂｆｕｓｃａｔｅｄＣｌａｓｓＮｕｍ＝２」は、該当のｄｌｌファイルに含まれる２３個のクラスのうち、２個のクラスだけに難読化が適用されていることを意味してよい。また、図７の表７００において、「ＴｏｔａｌＯｂｆｕｓｃａｔｅｄＭｅｔｈｏｄＮｕｍ＝７」は、該当のｄｌｌファイルに含まれる２３個のメソッドのうち、７個のクラスだけに難読化が適用されていることを意味してよい。

このとき、保安性評価システム３００または難読化探知モジュール３４１は、このような難読化が適用されたクラスの数および／または難読化が適用されたメソッドの数に基づき、該当のｄｌｌファイルの難読化観点の危険等級を決定してよい。例えば、全体クラス／メソッドの数のうち、難読化が適用されたクラス／メソッドの数に対する割合に基づいて難読化観点の危険等級が決定されてよい。より具体的な例として、このような割合が高いほど、相対的に難読化観点の危険等級は低くなってよい。

図８は、本発明の一実施形態における、パースされたｓｏファイルに対する難読化観点の分析情報の例を示した図であり、図９は、本発明の一実施形態における、パースされたｓｏファイルに対する難読化観点の分析情報の他の例を示した図である。

図８の表８００は、「ｌｉｂｏｐｅｎａｌ．ｓｏ」ファイルに対する難読化観点の危険等級が安全（ＳＡＦＥ）等級であることを示しており、図９の表９００は、「ｌｉｂｎｍｓｃｒａｓｈ６４−ｖ１．ｓｏ」ファイルに対する難読化観点の危険等級がクリティカル（ＣＲＩＴＩＣＡＬ）等級であることをそれぞれ示している。

このために、保安性評価システム３００または難読化探知モジュール３４１は、ｓｏファイルそれぞれに含まれる項目に難読化が適用されているかを判断し、このような難読化適用の程度に応じて難読化観点の危険等級を決定してよい。例えば、図８および図９では、ｓｏファイルそれぞれが含む項目として、セクションヘッダ（ｓｅｃｔｉｏｎＨｅａｄｅｒ）、ストリングス（ｓｔｒｉｎｇｓ）、ストリングテーブル（ｓｔｒｉｎｇＴａｂｌｅ）、シンボルテーブル（ｓｙｍｂｏｌＴａｂｌｅ）、およびコード（ｃｏｄｅ）を示している。ここで、「ｙｅｓ」は難読化が適用されていることを意味する値であってよく、「ｎｏ」は難読化が適用されていないことを意味する値であってよい。

このとき、図８の実施形態では、「ｌｉｂｏｐｅｎａｌ．ｓｏ」ファイルのセクションヘッダとシンボルテーブルに難読化が適用されており、「ｌｉｂｏｐｅｎａｌ．ｓｏ」ファイルのコードがパッキング（「ｃｏｄｅｐａｃｋｉｎｇ＝ｙｅｓ」）されているため、「ｌｉｂｏｐｅｎａｌ．ｓｏ」ファイルの難読化観点の危険等級が低く決定された例を示している。コードがパッキングされている場合、パッキングされたコードの本来のコードは簡単には取得できないため、コードパッキングの有無も難読化の適用有無として活用されてよい。

これに対して、図９の実施形態では、「ｌｉｂｎｍｓｃｒａｓｈ６４−ｖ１．ｓｏ」ファイルと関連し、予め選定された項目すべてに対して難読化が適用されていないため、「ｌｉｂｎｍｓｃｒａｓｈ６４−ｖ１．ｓｏ」ファイルの難読化観点の危険等級が高く決定された例を示している。

このように、保安性評価システム３００は、ファイルの種類に応じて互いに異なる種類の項目（一例として、ｄｌｌファイルではクラスやメソッドの項目、ｓｏファイルではセクションヘッダ、ストリング、ストリングテーブル、シンボルテーブル、および／またはコードなどの項目）に対する難読化の適用有無を確認し、このような難読化の適用有無に応じて該当のファイルの難読化観点の危険等級を自動で決定して分析情報を生成することができる。

保安性評価システム３００は、難読化観点と脆弱性観点、および／または保安ソリューション観点のそれぞれについて観点別パターン情報を予め生成および管理し、このような観点別パターン情報を利用することにより、ファイル別に難読化観点の分析情報と脆弱性観点の分析情報、および／または保安ソリューション観点の分析情報を生成してよい。生成された分析情報は関係者に提供されてよい。また、関係者から追加の観点別パターン情報がさらに入力されることもある。例えば、既存のオープンソースから新たな脆弱性が発見されたり、既に提供された分析情報に基づいて難読化や脆弱性などを分析するための新たなパターン情報が開発されたりすることがある。このために、保安性評価システム３００は、入力された観点別パターン情報を予め格納されている観点別パターン情報に追加することにより、予め格納されている観点別パターン情報を更新してよい。このとき、新たなパターン情報による追加分析のために、登録されているパッケージファイルに対する追加分析が行われてよい。

図１０は、本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第１例を示したブロック図であり、図１１は、本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第１例を示したフローチャートである。

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

段階１１１０において、観点別パターン情報格納部１０１０は、パッケージファイルを難読化観点および脆弱性観点によって分析するための観点別パターン情報を格納してよい。パターン情報は、観点別、ファイルの種類別、および／またはプラットフォームの種類別などによって登録されたパッケージファイルをどのような方式で分析するかに関する情報を含んでよい。

段階１１２０において、パッケージファイル登録部１０２０は、アプリケーションのインストールおよび駆動のために利用者に配布するためのパッケージファイルの登録を受けてよい。例えば、パッケージファイル登録部１０２０は、開発者の端末からネットワークを介してサーバ１５０に送信されたパッケージファイル、あるいは別の記録媒体からサーバ１５０に入力されたパッケージファイルを登録してよい。登録されたパッケージファイルは、該当のアプリケーションを利用しようとする利用者に配布されてよいが、その前に、一定の水準以上の保安性を提供するために保安性評価が実施されてよい。

段階１１３０において、分析情報生成部１０３０は、登録されたパッケージファイルを観点別パターン情報に基づいて分析し、難読化観点の分析情報および脆弱性観点の分析情報を生成してよい。

例えば、分析情報生成部１０３０は、登録されたパッケージファイルを分解してパッケージファイルに含まれるファイルを識別してよい。また、分析情報生成部１０３０は、識別されたファイルの拡張子に基づいて、分析を必要とするファイルを観点別に識別して、観点別に識別されたファイルごとに対応する観点の分析情報を生成してよい。

より具体的には、観点別パターン情報のうちの難読化観点のパターン情報は、登録されたパッケージファイルに含まれるファイルのうち、難読化の観点によって識別されたファイルから項目別難読化の適用有無を識別するためのパターン情報を含んでよい。

一実施形態において、項目別難読化の適用有無は、難読化の観点によって識別されたファイルが含むメソッドとクラスそれぞれに対する難読化の適用有無を含んでよい。この場合、分析情報生成部１０３０は、段階１１３０において、難読化観点のパターン情報に基づき、難読化の観点によって識別されたファイルから難読化が適用されたメソッドおよびクラスを識別し、対象ファイル別に、（１）難読化が適用されたメソッドの数、（２）難読化が適用されたクラスの数、（３）難読化が適用されたメソッドの数および難読化が適用されたクラスの数に基づいて決定される危険等級を含む難読化観点の分析情報を生成してよい。このような分析情報の生成については、図６および図７を参照しながら詳しく説明したとおりである。

他の実施形態において、項目別難読化の適用有無は、難読化の観点によって識別されたファイルが含むセクションヘッダ、ストリング、ストリングテーブル、シンボルテーブル、およびコードのうちの少なくとも１つの項目に対応する情報それぞれの難読化の適用有無を含んでよい。この場合、分析情報生成部１０３０は、段階１１３０において、難読化観点のパターン情報に基づき、難読化の観点によって識別されたファイルから難読化が適用された項目を識別し、対象ファイル別に、（１）難読化が適用された項目の種類、および（２）難読化が適用された項目の種類に基づいて決定される危険等級を含む難読化観点の分析情報を生成してよい。

また、観点別パターン情報のうちの脆弱性観点のパターン情報は、脆弱性が存在するものとして知られているプロトコル、ライブラリ、およびＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）のうちの少なくとも１つに関する脆弱性情報を含んでよい。この場合、分析情報生成部１０３０は、段階１１３０において、脆弱性観点のパターン情報に基づき、登録されたパッケージファイルに含まれるファイルのうちから脆弱性情報に対応するプロトコル、ライブラリ、またはＡＰＩを含むファイルを識別し、（１）識別されたファイルの識別子、および（２）識別されたファイルに含まれる脆弱性の種類に基づいて決定される危険等級を含む脆弱性観点の分析情報を生成してよい。

また、上述したように、保安ソリューション観点の分析情報がさらに生成されてもよい。例えば、観点別パターン情報格納部１０１０は、段階１１１０において、パッケージファイルを保安ソリューション観点によって分析するための観点別パターン情報をさらに格納してよい。この場合、分析情報生成部１０３０は、段階１１３０において、登録されたパッケージファイルを保安ソリューション観点に対応する観点別パターン情報に基づいてさらに分析して保安ソリューション観点の分析情報をさらに生成してよい。

段階１１４０において、分析情報提供部１０４０は、生成された分析情報を提供してよい。上述したように生成された分析情報は、関係者（一例として、サーバ１５０の管理者またはアプリケーションパブリッシャの保安検査チーム）に提供されてよい。上述したように、パッケージファイルに含まれるファイル間の参照関係に関する分析情報がさらに生成されてもよい。この場合、分析情報提供部１０４０は、参照関係に関する分析情報をさらに提供してよい。分析および提供される情報については、上述で詳しく説明したとおりである。

段階１１５０において、追加パターン情報処理部１０５０は、分析情報の提供と関連する追加の観点別パターン情報の入力を受けてよい。例えば、追加パターン情報処理部１０５０は、分析情報が提供される関係者から追加の観点別パターン情報の入力を受けてよい。より具体的な例として、オープンソースに対する新たな脆弱性が発見されることにより、新たな脆弱性を探知するためのパターン情報が関係者から入力されてよい。また、新たなファイルフォーマットなどが開発されて常用化される場合、このような新たなファイルフォーマットによるパッケージファイルを分析するための観点別パターン情報が入力されてもよい。

段階１１６０において、追加パターン情報処理部１０５０は、入力された観点別パターン情報を利用して、格納されている観点別パターン情報を更新してよい。このとき、追加パターン情報処理部１０５０は、入力された観点別パターン情報を、格納されている観点別パターン情報に追加してもよいし、入力された観点別パターン情報と予め格納されている観点別パターン情報を交換してもよい。

段階１１７０において、分析情報生成部１０３０は、入力された観点別パターン情報または更新された観点別パターン情報に基づいて、登録されたパッケージファイルそれぞれを再分析し、難読化観点の分析情報および脆弱性観点の分析情報を登録されたパッケージファイルごとにそれぞれ再生成してよい。

段階１１８０において、分析情報提供部１０４０は、再生成された分析情報を提供してよい。

また、保安性評価システムは、脆弱性を例外処理するための機能を提供してよい。例えば、保安性評価システムで脆弱性観点のパターン情報に基づいて脆弱性が存在するかを探知するにあたり、プログラム的にファイルに対する正確な脆弱性の探知がなされない場合が存在する。例えば、特定の脆弱性観点のパターン情報に基づいて正常なファイルが探知され、このようなパターン情報をプログラム的に修正することができない場合が存在する。この場合、保安性評価システムは、周知の脆弱性に対する脆弱性観点のパターン情報であったとしても、脆弱性探知から除外させるための例外処理機能を提供してよい。

また、保安性評価システムは、難読化と脆弱性の分析結果に対する指標管理機能を提供してよい。例えば、保安性評価システムは、特定の脆弱性が探知されたる数を時間に応じて記録し、一定期間単位で該当の脆弱性が探知される回数が増加しているか減少しているかに関する情報のような統計的情報を提供してよい。他の例として、保安性評価システムは、パッケージファイルに対する適用が増加している難読化技術あるいは適用が減少している難読化技術に関する情報のような指標を提供してもよい。

図１２は、本発明の一実施形態における、Ｄｅｘファイルの難読化の適用有無を決定する例を示した図である。保安性評価システム３００に登録されるアンドロイドアプリケーションパッケージ（ＡＰＫ）は、難読化が適用されていない状態または難読化が適用された状態のＤｅｘファイルを含んでよい。このとき、保安性評価システム３００は、登録されたアンドロイドアプリケーションパッケージに含まれるＤｅｘファイルに難読化が適用されているかどうかを決定してよい。

図１２に示された第１Ｄｅｘファイル１２１０は、難読化が適用されていない状態のファイルを示してよく、第２Ｄｅｘファイル１２２０および第３Ｄｅｘファイル１２３０は、難読化が適用された状態のファイルを示してよい。言い換えれば、第１Ｄｅｘファイル１２１０は、第２Ｄｅｘファイル１２２０および第３Ｄｅｘファイル１２３０のように２つのＤｅｘファイル（マルチＤｅｘ（ｍｕｌｔｉ ｄｅｘ））で難読化されてよい。このとき、第２Ｄｅｘファイル１２２０は、第１Ｄｅｘファイル１２１０からクラス（クラスＡ（ＣｌａｓｓＡ）、クラスＢ（ＣｌａｓｓＢ）、クラスＣ（ＣｌａｓｓＣ）、クラスＤ（ＣｌａｓｓＤ）、およびクラスＥ（ＣｌａｓｓＥ）の５つのクラス、以下、「クラスＡ〜Ｅ」とする）が除去されたファイルであり、除去されたクラスは暗号化され、暗号化されたクラスＡ〜Ｅ（Ｃｒｙｐｔｅｄ ＣｌａｓｓＡ〜Ｅ）１２３１が含まれる新たなＤｅｘファイルである第３Ｄｅｘファイル１２３０がアンドロイドアプリケーションパッケージに含まれるとする。

この場合、図１２の実施形態において、Ｄｅｘファイルに含まれなければならないクラス（クラスＡ〜Ｅ）は、第３Ｄｅｘファイル１２３０に暗号化されて格納されているため、第２Ｄｅｘファイル１２２０は、第３Ｄｅｘファイル１２３０をメモリにロードするための機能を含まなければならない。言い換えれば、図１２に示すように、第２Ｄｅｘファイル１２２０に含まれるアプリケーションクラス（Ａｐｐｌｉｃａｔｉｏｎ）１２２１は、このようなＤｅｘファイルのロードのための機能を含む必要がある。アンドロイドアプリケーションパッケージでは、ＤｅｘファイルのロードのためのＡＰＩが提供されていることから、第２Ｄｅｘファイル１２２０に含まれるアプリケーションクラス１２２１は、このようなＡＰＩコールのための機能（ＤｅｘＬｏａｄｅｒ）を含んでよい。例えば、アプリケーションクラス１２２１により、Ｄｅｘファイル（図１２の実施形態では第３Ｄｅｘファイル１２３０）のロードのためのクラスローダ（「ＣｌａｓｓＬｏａｄｅｒ」または「ＤｅｘＣｌａｓｓＬｏａｄｅｒ」）クラスと、このようなクラスローダクラスが含むロードクラス（「ＬｏａｄＣｌａｓｓ」）メソッドが呼び出されなければならない。

このような観点において、１つのＤｅｘファイル（一例として、図１２の第２Ｄｅｘファイル１２２０）に対する難読化の適用有無を探知するために、保安性評価システム３００は、該当のＤｅｘファイルに含まれるアプリケーションクラス（一例として、図１２の第２Ｄｅｘファイル１２２０に含まれるアプリケーションクラス１２２１）により、Ｄｅｘファイル（一例として、図１２の第３Ｄｅｘファイル１２３０）のロードのためのＡＰＩコールがなされるかを確認してよい。

より具体的な例として、アンドロイドアプリケーションパッケージでは、上述した例におけるクラスローダクラスおよびクラスローダクラスに含まれるロードクラスメソッドが呼び出されるかどうかに基づき、該当のＤｅｘファイルの難読化の適用有無が決定されてよい。言い換えれば、保安性評価システム３００は、難読化の適用有無を決定しようとするＤｅｘファイルにおいて、クラスローダクラスおよびロードクラスメソッドの呼び出し有無を確認してよい。

図１２の第１Ｄｅｘファイル１２１０は、クラスＡ〜Ｅをすべて含んでいるため、別のＤｅｘファイルをロードするためのＡＰＩコールが成なされないはずであり、これにより、保安性評価システム３００は、第１Ｄｅｘファイル１２１０に難読化が適用されていないことを把握できるようになる。一方、図１２の第２Ｄｅｘファイル１２２０は、第３Ｄｅｘファイル１２３０がロードされることによって暗号化されたクラスＡ〜Ｅ １２３１を得ることができるため、第３Ｄｅｘファイル１２３０をロードするためのＡＰＩコールがなされるはずであり、保安性評価システム３００は、このようなＡＰＩコールの探知により、第２Ｄｅｘファイル１２２０には難読化が適用されていることを把握することができる。

図１３は、本発明の一実施形態における、ＡＰＩコールの探知過程の例を示した図である。

過程１において、保安性評価システム３００は、ＡＰＫ１３００を登録してよい。ＡＰＫ１３００は、アプリケーションの利用者に配布するためにアプリケーションパブリッシャに登録されてよい。上述したように、保安性評価システム３００は、アプリケーションパブリッシャが、登録されているアプリケーションのパッケージファイルを配布するためのサービスを提供する装置（一例として、サーバ１５０）に実現されてもよいし、上述した装置とネットワーク１７０を介して通信する別のシステムとして実現されてもよい。例えば、保安性評価システム３００は、サーバ１５０に登録されるＡＰＫ１３００を、ネットワーク１７０を介して受信して登録してよい。

過程２において、保安性評価システム３００は、アンドロイドマニフェストファイル１３１０からアプリケーションクラス１３２１のクラス名を抽出してよい。アンドロイドアプリケーションパッケージが「ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ」のようなアンドロイドマニフェストファイル１３１０を含むことや、このようなアンドロイドマニフェストファイル１３１０がアプリケーションクラス１３２１のクラス名を含むことは、周知のとおりである。

過程３において、保安性評価システム３００は、抽出されたクラス名によって識別されるアプリケーションクラス１３２１からすべての呼び出しを収集してよい。例えば、保安性評価システム３００は、抽出されたクラス名を利用して第１Ｄｅｘファイル１３２０に含まれたアプリケーションクラス１３２１を識別してよく、識別されたアプリケーションクラス１３２１に含まれるすべてのメソッドそれぞれの本体命令（ｂｏｄｙ ｉｎｓｔｒｕｃｔｉｏｎ）で呼び出しされるクラスとメソッドに対する呼び出しリストを生成してよい。一例として、保安性評価システム３００は、図３を参照しながら説明したパースモジュール３３０で生成される呼び出し関係を基盤として上述した呼び出しリストを生成してよい。

過程４において、保安性評価システム３００は、他のＤｅｘファイル（図１３の実施形態では第２Ｄｅｘファイル１３３０）をロードするためのＡＰＩコールを探知してよい。このために、保安性評価システム３００は、呼び出しリストにより、クラスローダ（「ＣｌａｓｓＬｏａｄｅｒ」または「ＤｅｘＣｌａｓｓＬｏａｄｅｒ」）クラスおよびロードクラス（「ＬｏａｄＣｌａｓｓ」）メソッドが呼び出されたかを確認してよい。言い換えれば、クラスローダクラスおよびロードクラスメソッドの呼び出しが他のＤｅｘファイルをロードするためのＡＰＩコールとして探知されてよい。

ＡＰＩコールが探知されると、保安性評価システム３００は、過程５のように、第１Ｄｅｘファイル１３２０に難読化が適用されたものと決定してよい。ＡＰＩコールが探知されなかった場合、保安性評価システム３００は、過程６のように、第１Ｄｅｘファイル１３２０に難読化が適用されていないものと決定してよい。

ただし、アプリケーションクラスの実現により、アプリケーションクラスが含むメソッドの本体命令でＡＰＩコールがなされずに、該当のメソッドによって呼び出される他のメソッドの本体命令でＤｅｘファイルのロードのためのＡＰＩコールがなされることもある。このような場合のＡＰＩコールを探知するために、保安性評価システム３００は、呼び出しリストによって識別されるメソッドの本体命令で収集される他の呼び出しリストによってＡＰＩコールを探知する方式により、アプリケーションクラスが含むメソッドによって直接的／間接的に呼び出されるすべてのメソッドでＡＰＩコールがなされるかを確認してもよい。このとき、アプリケーションクラスが含むメソッドにより、直接系／間接的に呼び出されるすべてのメソッドでＡＰＩコールがなされなかった場合、保安性評価システム３００は、第１Ｄｅｘファイル１３２０に難読化が適用されていないものと決定してよい。

第２Ｄｅｘファイル１３３０の場合には、アンドロイドマニフェストファイル１３１０から関連するアプリケーションクラスのクラス名が抽出されないため、難読化の適用有無が探知されなくてもよい。

また、上述したように、マルチＤｅｘを利用する難読化方式の他にも、メソッドの本体命令全体を暗号化する難読化方式が存在する。

図１４は、本発明の一実施形態における、本体命令の暗号化を利用して難読化を探知する例を示した図である。図１４は、Ｄｅｘファイルが含む特定のメソッド１４１０の演算コード１４１１を暗号化や符号化、またはダミー（ｄｕｍｍｙ）コードの追加などによって難読化し、変形された演算コード１４１２を含むメソッド１４２０が生成された例を示している。

このとき、Ｄｅｘファイルはコンパイルによって生成されるという点を考慮すると、変形された演算コード１４１２は、任意のコードに代替されるのではなく、コンパイルが可能なコードに代替されなければならないことから、数種類のパターンを有するようになる。例えば、変形された演算コード１４１２は、レジスタに影響を与えないか無意味な命令のパターン（一例として、ＡＲＭアセンブリ命令におけるＬＤＲ命令の連続や分岐、またはＬＳＬＳ命令の連続）を含むようになる。

また、正常なバイトコードは、一定のヘキサ（ｈｅｘａ）値の連続によってコードが予め定義されている。例えば、下のウェブサイトでは、ダルビックＯＰコードについて説明している。

−ウェブサイト（ｈｔｔｐ：／／ｐａｌｌｅｒｇａｂｏｒ．ｕｗ．ｈｕ／ａｎｄｒｏｉｄｂｌｏｇ／ｄａｌｖｉｋ＿ｏｐｃｏｄｅｓ．ｈｔｍｌ）

各メソッドは、「．ｌｏｃａｌ」というディレクティブ（ｄｉｒｅｃｔｉｖｅ）により、使用されるローカル変数レジスタ（ｌｏｃａｌ ｖａｒｉａｂｌｅ ｒｅｇｉｓｔｅｒ）の個数を把握してよい。「．ｌｏｃａｌ」が２であれば、ｖ０、ｖ１のように、２つのローカル変数レジスタが使用されたことを意味してよい。このとき、「０Ｂ」というヘキサ値が発見される場合、その後にあるヘキサ値はローカル変数レジスタを意味してよい。例えば、「０Ｂ」というヘキサ値は、上述したウェブサイトで説明するように、ＯＰコードネーム「ｍｏｖｅ−ｒｅｓｕｌｔ−ｏｂｊｅｃｔ ｖｘ」に対応しており、このようなＯＰコードは、以前のメソッド呼び出し（ｉｎｖｏｃａｔｉｏｎ）のｌｏｎｇ／ｄｏｕｂｌｅ結果値を「ｖｘ」と「ｖｘ＋１」に移動させる命令であることが分かる。言い換えれば、「０Ｂ０２」は、以前の命令実施のｌｏｎｇ／ｄｏｕｂｌｅ結果値を「ｖ２」と「ｖ３」の２つのローカル変数レジスタに移動させるのである。この場合、保安性評価システム３００は、「．ｌｏｃａｌ」によって確認したローカル変数レジスタの個数と「０Ｂ０２」によって要求されるローカル変数レジスタに基づき、要求されるローカル変数レジスタが可用であるかを確認してよい。他の例として、ヘキサ値「６Ｅ」は、上述したウェブサイトで説明したように、ＯＰコード「ｉｎｖｏｋｅ−ｖｉｒｔｕａｌ」後に現在のインスタンスのパラメータに該当するローカル変数レジスタとメソッドパラメータに対応するローカル変数レジスタを明示しなければならない。この場合にも、保安性評価システム３００は「．ｌｏｃａｌ」を利用してこのようなレジスタが可用なレジスタであるかを確認することができ、このような方法により、メソッド１４１０の演算コードが一般的な（または正常な）コードであるか、難読化された（または変形された）コードであるかを判別できるようになる。

したがって、保安性評価システム３００は、整形化されたパターンを予め格納および管理している間に、該当のパターンの命令を処理する演算コードのメソッドを探知することにより、Ｄｅｘファイルに対する難読化の適用有無を決定することができる。言い換えれば、図１４の実施形態において、保安性評価システム３００は、予め格納されたパターンを演算コード１４１１や変形された演算コード１４１２によって検索し、予め格納されたパターンが発見される変形された演算コード１４１２該当によってメソッド１４２０に難読化が適用されたことを判断してよいが、これは、該当のメソッド１４２０を含むＤｅｘファイルに難読化が適用されたことを意味してよい。

このとき、Ｄｅｘファイルが含むメソッド別に難読化の適用有無が決定されるようになるため、保安性評価システム３００は、実施形態によっては、Ｄｅｘファイルが含むメソッドのうち、難読化が適用されたメソッドの比重に基づいて難読化による保安性等級を決定してもよい。

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

本発明の実施形態に係る保安性評価システム３００は、上述したサーバ１５０のようなコンピュータ装置の形態で実現されてよい。また、図１５に示すように、サーバ１５０のプロセッサ２２２は、保安性評価システム３００を実現するための構成要素として、ＡＰＫ登録部１５１０、アプリケーションクラス検索部１５２０、ＡＰＩコール確認部１５３０、難読化決定部１５４０、保安性決定部１５５０、および情報提供部１５６０を備えてよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図１６の保安性評価方法に含まれる段階１６１０〜段階１６６０を実行してよい。このとき、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１に含まれるオペレーティングシステムのコードや少なくとも１つのプログラムのコードによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２２の構成要素は、サーバ１５０に格納されたコードが提供する制御命令に従ってプロセッサ２２２によって実行される、プロセッサ２２２の互いに異なる機能の表現であってよい。例えば、プロセッサ２２２が上述した制御命令に従ってアンドロイドアプリケーションパッケージ（ＡＰＫ）を登録するプロセッサ２２２の機能的表現として、ＡＰＫ登録部１５１０が使用されてよい。

段階１６１０において、ＡＰＫ登録部１５１０は、アンドロイドアプリケーションパッケージを登録してよい。アンドロイドアプリケーションパッケージは、アプリケーションの利用者に配布するためにアプリケーションパブリッシャに登録されてよい。上述したように、保安性評価システムは、アプリケーションパブリッシャが、登録されたアプリケーションのパッケージファイルを配布するためのサービスを提供する装置に実現されてもよいし、上述した装置とネットワーク１７０を介して通信する別のシステムとして実現されてもよい。例えば、保安性評価システム３００は、アプリケーションパブリッシャに登録されたアンドロイドアプリケーションパッケージを、ネットワーク１７０を介して受信して登録してもよい。

段階１６２０において、アプリケーションクラス検索部１５２０は、アンドロイドアプリケーションパッケージに含まれるＤｅｘファイルからアプリケーションクラスを検索してよい。一例として、アプリケーションクラス検索部１５２０は、アンドロイドアプリケーションパッケージに含まれる「ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ」のようなアンドロイドマニフェストファイルから、アプリケーションクラスのクラス名を抽出してよく、抽出されたクラス名を利用して、Ｄｅｘファイルから抽出されたクラス名に対応するアプリケーションクラスを検索してよい。

段階１６３０において、ＡＰＩコール確認部１５３０は、アプリケーションクラスに含まれるメソッドの本体命令で呼び出されるクラスおよびメソッドを基盤とし、そのアンドロイドアプリケーションパッケージにさらに含まれる他のＤｅｘファイルをロードするためのＡＰＩコールがなされたかを確認してよい。上述したように、ＡＰＩコール確認部１５３０は、識別されたアプリケーションクラスに含まれるすべてのメソッドそれぞれの本体命令で呼び出されるクラスとメソッドについての呼び出しリストを生成してよい。このとき、ＡＰＩコール確認部１５３０は、呼び出しリストにより、クラスローダ（「ＣｌａｓｓＬｏａｄｅｒ」または「ＤｅｘＣｌａｓｓＬｏａｄｅｒ」）クラスおよびロードクラス（「ＬｏａｄＣｌａｓｓ」）メソッドが呼び出されたかを確認してよい。言い換えれば、クラスローダクラスおよびロードクラスメソッドの呼び出しが、他のＤｅｘファイルをロードするためのＡＰＩコールとして探知されてよい。

生成された呼び出しリストからクラスローダクラスおよびロードクラスメソッドが検索されなければ、ＡＰＩコール確認部１５３０は、呼び出しリストによって識別されるメソッドの本体命令から収集される呼び出しリストにより、クラスローダクラスおよびロードクラスメソッドの呼び出しがあったかどうかをさらに検索してよい。このように、ＡＰＩコールの確認過程は、アプリケーションクラスが含むすべてのメソッドから直接的に呼び出されるクラスとメソッドだけではなく、呼び出されるメソッドから再び呼び出されるクラスとメソッドに対しても繰り返し行われることで、アプリケーションクラスに含まれるメソッドによって直接的／間接的に呼び出されるすべてのクラスとメソッドに対して実行されてよい。

段階１６４０において、難読化決定部１５４０は、他のＤｅｘファイルをロードするためのＡＰＩコールが存在すると確認された場合、Ｄｅｘファイルに難読化が適用されていると決定してよい。他のＤｅｘファイルをロードするためのＡＰＩコールが確認されない場合、難読化決定部１５４０は、段階１６４０において、Ｄｅｘファイルに難読化が適用されていないと決定してよい。

段階１６５０において、保安性決定部１５５０は、Ｄｅｘファイルに難読化が適用されたかに少なくとも基づき、登録されたアンドロイドアプリケーションパッケージの保安性を決定してよい。例えば、登録されたアンドロイドアプリケーションパッケージの保安性は、Ｄｅｘファイルに難読化が適用されている場合の方が、Ｄｅｘファイルに難読化が適用されていない場合よりも相対的により高く決定されてよい。

段階１６６０において、情報提供部１５６０は、Ｄｅｘファイルに難読化が適用されているかどうかに関する情報を提供してよい。例えば、特定のＤｅｘファイルに対し、該当のＤｅｘファイルのファイル名、難読化の適用有無などに関する情報が共に提供されてよい。例えば、関連情報は、図３を参照しながら説明したように、管理者などに提供されてよい。

図１７は、本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第３例を示したブロック図であり、図１８は、本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第３例を示したフローチャートである。

本実施形態に係るサーバ１５０のプロセッサ２２２は、保安性評価システム３００を実現するための構成要素として、ＡＰＫ登録部１７１０、ジャンクコードパターン管理部１７２０、ジャンクコードパターン検索部１７３０、および難読化決定部１７４０を備えてよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図１８の保安性評価方法に含まれる段階１８１０〜段階１８４０を実行してよい。このとき、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１に含まれるオペレーティングシステムのコードや少なくとも１つのプログラムのコードによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２２の構成要素は、サーバ１５０に格納されたコードが提供する制御命令に従ってプロセッサ２２２によって実行される、プロセッサ２２２の互いに異なる機能の表現であってよい。

段階１８１０において、ＡＰＫ登録部１７１０は、アンドロイドアプリケーションパッケージを登録してよい。このようなＡＰＫ登録部１７１０は、図１５を参照しながら説明したＡＰＫ登録部１５１０に対応してよい。

段階１８２０において、ジャンクコードパターン管理部１７２０は、探索しようとするジャンクコードパターンの入力を受けて管理してよい。図１４を参照しながら説明したように、ジャンクコードパターンは、メソッドの本体命令に対する難読化によって示されるようになるパターンを予め設定して活用してよい。このとき、段階１８２０は、段階１８１０以前に実行されてもよい。

段階１８３０において、ジャンクコードパターン検索部１７３０は、Ｄｅｘファイルに含まれるメソッドの本体命令からジャンクコードパターンを検索してよい。Ｄｅｘファイルはコンパイルによって生成されることから、メソッドの本体命令に対する難読化によって変換されたコードは任意のランダムな値を含むことはできず、一定のパターンを有するようになる。したがって、ジャンクコードパターン検索部１７３０は、このようなジャンクコードパターンがメソッドの本体命令から検索されるかどうかを確認してよい。

段階１８４０において、難読化決定部１７４０は、ジャンクコードパターンが検索される場合、Ｄｅｘファイルに難読化が適用されていると決定してよい。このとき、Ｄｅｘファイルに難読化が適用されているかどうかに少なくとも基づき、登録されたアンドロイドアプリケーションパッケージの保安性を決定してよい。あるいは、メソッド別に難読化の有無の決定が可能であるため、メソッド全体に対する難読化されたメソッドの割合などに基づいて保安性が決定されてもよい。また、難読化が適用されているメソッドに関する情報は、管理者などに提供されてもよい。

実施形態によって、図１５および図１６の実施形態と図１７および図１８の実施形態とが結合されてもよい。例えば、登録されるＡＰＫに対し、ＤｅｘファイルのロードのためのＡＰＩコールの有無についての探知とジャンクコードパターンの探知が並列的に実行されてよい。このとき、難読化決定部１５４０または難読化決定部１７４０は、他のＤｅｘファイルをロードするためのＡＰＩコールが存在すると確認されたる場合や、ジャンクコードパターンが検索される場合、Ｄｅｘファイルに難読化が適用されていると決定してよい。この場合、保安性は、並列的にそれぞれ決定された保安性の加重合計などによって決定されてよく、探知されたそれぞれの情報が管理者などに提供されてよい。

図１９および図２０は、本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルに対する難読化を探知する第１例を示した図である。

図１９は、ＥＬＦファイルが含むセクションヘッダテーブル１９１０と、セクションヘッダテーブル１９１０に含まれる動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）のヘッダ１９１１を示している。また、図１９は、ＥＬＦファイルに含まれる動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）のシンボルエントリーテーブル（Ｓｙｍｂｏｌ Ｅｎｔｒｙ Ｔａｂｌｅ）１９２０をさらに示しており、動的リンクシンボルテーブルセクションのヘッダ１９１１でシンボルエントリーテーブル１９２０をポインティングしている様子を示している。シンボルエントリーテーブル１９２０は、インポート関数（Ｉｍｐｏｒｔ Ｆｕｎｃｔｉｏｎ）およびエクスポート関数（Ｅｘｐｏｒｔ Ｆｕｎｃｔｉｏｎ）の名称とアドレスを並べているテーブルであってよい。

ＥＬＦファイルにおいて、セクションヘッダテーブル１９１０は、ＥＬＦファイルに含まれるセクションそれぞれに対する名称、メモリ、開始アドレス、ファイルオフセット、サイズ、整列方式、表現方式などの情報を定義している。セクションは、上述した．ｄｙｎｓｙｍセクションの他にも、動的リンク情報セクション（．ｄｙｎａｍｉｃセクション）、読み取り専用データセクション（．ｒｏｄａｔａセクションまたは．ｒｄａｔａセクション）、プロセス初期化時に使用されるコードを含むセクション（．ｉｎｉｔセクションまたは．ｉｎｉｔ＿ａｒｒａｙセクション）などのような多様なセクションを含んでおり、これは周知のとおりである。例えば．ｄｙｎｓｙｍセクションに関する情報は、セクションヘッダテーブル１９１０で．ｄｙｎｓｙｍセクションのヘッダに基づいて定義されてよく、．ｄｙｎｓｙｍセクションのヘッダは、このような定義された値のうちの少なくとも一部（一例として．ｄｙｎｓｙｍセクションの開始アドレスとファイルオフセット、およびサイズ）によって．ｄｙｎｓｙｍセクションをポインティングしてよい。

図２０は、図１９の動的リンクシンボルテーブルセクションのヘッダ１９１１に定義された値を難読化する例として、定義された値をヌル（Ｎｕｌｌ）２０１０に代替した例を示している。この場合、動的リンクシンボルテーブルセクションのヘッダ１９１１は、シンボルエントリーテーブル１９２０をポインティングできなくなり、これによってＥＬＦファイルのセクションヘッダが難読化されるようになる。

このように、動的リンクシンボルテーブルセクションのヘッダ１９１１に定義された値をヌル２０１０や他の情報に変更して難読化することにより、ＥＬＦファイルで利用されるシンボルを難読化してよい。このとき、保安性評価システム３００は、動的リンクシンボルテーブルセクションのヘッダ１９１１に定義された値を分析することにより、このようなセクションヘッダの難読化を探知してよい。

例えば、保安性評価システム３００は、動的リンクシンボルテーブルセクションのヘッダ１９１１がヌル２０１０を含むという第１条件、動的リンクシンボルテーブルセクションのヘッダ１９１１のパース（ｐａｒｓｉｎｇ）が不可能であるという第２条件、および動的リンクシンボルテーブルセクションのヘッダ１９１１に含まれる情報がセクションのうちの動的リンク情報セクション（．ｄｙｎａｍｉｃセクション）に存在しないという第３条件のうちのいずれか１つの条件が満たされる場合、セクションヘッダに難読化が適用されていると決定してよい。

第１条件は、図２０で説明するように、動的リンクシンボルテーブルセクションのヘッダ１９１１に定義された値がヌル２０１０に代替された条件を意味してよい。

一方、動的リンクシンボルテーブルセクションのヘッダ１９１１は、予め定義された構造を有しており、このような予め定義された構造によって動的リンクシンボルテーブルセクションのヘッダ１９１１をパースするための既存の方式が存在する。このとき、第２条件は、このような既存のパース方式によって動的リンクシンボルテーブルセクションのヘッダ１９１１のパースを試した結果、動的リンクシンボルテーブルセクションのヘッダ１９１１が正常にパースされないという条件を意味してよい。言い換えれば、動的リンクシンボルテーブルセクションのヘッダ１９１１が難読化された場合、保安性評価システム３００は、動的リンクシンボルテーブルセクションのヘッダ１９１１をパースすることができなくなり、したがって、第２条件が満たされることが確認されるようになる。

また、動的リンクシンボルテーブルセクションのヘッダ１９１１に予め定義された構造によって定義される値のうちの少なくとも一部は、動的リンク情報セクション（．ｄｙｎａｍｉｃセクション）にも含まれ、動的リンク情報セクション（．ｄｙｎａｍｉｃセクション）の値は変更されない。したがって、保安性評価システム３００は、動的リンクシンボルテーブルセクションのヘッダ１９１１に含まれる情報が、動的リンク情報セクション（．ｄｙｎａｍｉｃセクション）に存在するかを確認し、存在しない場合には、動的リンクシンボルテーブルセクションのヘッダ１９１１に含まれる値が変更されたものと決定してよい。言い換えれば、保安性評価システム３００は、第３条件が満たされることを確認できるようになる。

このような第１条件、第２条件、および第３条件のうちのいずれか１つの条件が満たされれば、保安性評価システム３００は、動的リンクシンボルテーブルセクションのヘッダ１９１１に難読化が適用されたものと決定するようになる。

図２１は、本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルに対する難読化を探知する第２例を示した図である。図２１の実施形態では、動的リンクシンボルテーブルセクションのヘッダ１９１１の代わりにシンボルエントリーテーブル１９２０の値に難読化を適用した例であって、インポート関数の名称２１１０とエクスポート関数の名称２１２０をヌルに変更した例を示している。

このような場合のために、保安性評価システム３００は、動的リンクシンボルテーブルセクションのヘッダ１９１１がポインティングしているシンボルエントリーテーブル１９２０を見つけ出し、インポート関数とエクスポート関数の値を分析して動的リンクシンボルテーブルセクションに難読化が適用されているかどうかを決定してよい。例えば、保安性評価システム３００は、インポート関数とエクスポート関数の値がヌルを含むか、アスキー（Ａｍｅｒｉｃａｎ Ｓｔａｎｄａｒｄ Ｃｏｄｅ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｒｃｈａｎｇｅ：ＡＳＣＩＩ）コードで表現されていない場合、セクション（動的リンクシンボルテーブルセクション）に難読化が適用されていると決定してよい。

図２２は、本発明の一実施形態における、登録されたパッケージファイルが含むＥＬＦファイルからシンボルに対する難読化を探知する第３例を示した図である。ＥＬＦファイルは、読み取り専用（ｒｅａｄ−ｏｎｌｙ）セクション（．ｒｄａｔａセクション２２１０または．ｒｏｄａｔａセクション）を含んでよく、セクションヘッダテーブル１９１０は、このような読み取り専用（ｒｅａｄ−ｏｎｌｙ）セクションのためのヘッダ（．ｒｄａｔａセクションヘッダ２２２０または．ｒｏｄａｔａセクションヘッダ）を含んでよい。

このような読み取り専用セクションに対する難読化は、読み取り専用セクションが含むテキストを暗号化または符号化することによってなされてよい。したがって、保安性評価システム３００は、読み取り専用セクションのためのヘッダに基づいて読み取り専用セクションを確認し、確認された読み取り専用セクションに含まれる読み取り専用値を分析することにより、読み取り専用セクションに対する難読化を探知してよい。

例えば、図２２の実施形態において、保安性評価システム３００は、ＥＬＦファイルのセクションヘッダテーブル１９１０から．ｒｄａｔａセクションヘッダ２２２０を識別し、識別された．ｒｄａｔａセクションヘッダ２２２０がポインティングする．ｒｄａｔａセクション２２３０を見つけ出して．ｒｄａｔａセクション２２３０に含まれる値を分析してよい。このとき．ｒｄａｔａセクション２２３０は．ｒｄａｔａセクション２２１０に含まれるテキストを難読化したセクションであってよく、保安性評価システム３００は、ｒｄａｔａセクション２２３０に含まれる値がヌルであるか、アスキーコードで表現されていない場合．ｒｄａｔａセクション２２１０とは異なり、．ｒｄａｔａセクション２２３０に対して難読化が適用されたことを確認してよい。

図２３は、本発明の一実施形態における、ＥＬＦファイルのＥＬＦヘッダに対する難読化を探知する例を示した図である。図２３において、第１ＥＬＦヘッダ２３１０は、難読化が適用されていないヘッダであって、セクションヘッダのサイズ２３１１、セクションヘッダの数２３１２、およびセクションのサイズ２３１３のような情報を含む例を示している。一方、第２ＥＬＦヘッダ２３２０は、難読化が適用されたヘッダであって、本来の値が操作された値２３２１に変更された例を示している。

このような難読化の探知のために、保安性評価システム３００は、ＥＬＦヘッダの非正常値を探知することによってＥＬＦヘッダに対する難読化の適用有無を決定してよい。例えば、ＥＬＦヘッダの正常な値は、一定範囲の値を有することがあるが、難読化が適用された場合にはこのような値の範囲を逸脱することがある。

このために、保安性評価システム３００は、ＥＬＦヘッダが含むセクションヘッダのサイズ、セクションヘッダの数、およびセクションのサイズのうちの少なくとも１つの項目に対する正常値の範囲を設定してよく、ＥＬＦヘッダからこのような少なくとも１つの項目の値を抽出してよく、抽出された値が設定された正常値の範囲を逸脱する場合、ＥＬＦヘッダに難読化が適用されたものと決定してよい。

例えば、図２３の実施形態において、第１ＥＬＦヘッダ２３１０から抽出される値は正常値の範囲に含まれるはずであり、第２ＥＬＦヘッダ２３２０から抽出される値は正常値の範囲を逸脱するはずである。このように、保安性評価システム３００は、このように抽出される値の非正常値が感知される場合、ＥＬＦヘッダに対して難読化が適用されたことを探知できるようになる。

図２４は、本発明の一実施形態における、実行コードを含むセクションのヘッダに対する難読化の適用有無を決定する例を示した図である。

上述したセクションヘッダテーブル１９１０は、実行コードを含むセクション（．ｔｅｘｔセクション）のヘッダを含んでよい。このとき、正常な．ｔｅｘｔセクションのヘッダ２４１０は、実行コードのサイズ２４１１を含んでよく、難読化方式のうちの１つとして、正常な．ｔｅｘｔセクションのヘッダ２４１０が含む実行コードのサイズ２４１１を操作する方式が存在する。図２４は、正常な．ｔｅｘｔセクションのヘッダ２４１０に難読化が適用されることにより、操作された値２４２１を含む難読化された．ｔｅｘｔセクションのヘッダ２４２０に変更された例を示している。

このような難読化の探知のために、保安性評価システム３００は、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）に含まれるシンボルエントリーテーブル１９２０から、エクスポートシンボルエントリー（図２４のエクスポート関数）に基づいて関数のアドレスを収集してよい。例えば、保安性評価システム３００は、このようなエクスポート関数のアドレスに基づいて関数のアドレスを繰り返し収集してよく、収集されたアドレスを利用して実行コードのサイズ２４１１を計算してよい。このとき、保安性評価システム３００は、正常な．ｔｅｘｔセクションのヘッダ２４１０から実行コードのサイズ２４１１を抽出してよく、抽出された実行コードのサイズ２４１１と計算された実行コードのサイズを比較することにより、正常な．ｔｅｘｔセクションのヘッダ２４１０には難読化が適用されていないものと決定してよい。

図２４の実施形態のように、難読化された．ｔｅｘｔセクションのヘッダ２４２０から操作された値２４２１が抽出される場合には、操作された値２４２１は本来の実行コードのサイズ２４１１と差があるため、計算された実行コードのサイズとは異なるようになり、このような比較により、保安性評価システム３００は、難読化された．ｔｅｘｔセクションのヘッダ２４２０に難読化が適用されたことを探知してよい。

図２５は、本発明の一実施形態における、コードに対する難読化を探知する例を示した図である。セクションヘッダテーブル１９１０は、プロセス初期化のためのコードを含むセクション（．ｉｎｉｔセクションおよび／または．ｉｎｉｔ＿ａｒｒａｙセクション）のヘッダを含んでよい。図２５では．ｉｎｉｔセクションのヘッダ２５１０と．ｉｎｉｔ＿ａｒｒａｙセクションのヘッダ２５２０をそれぞれ示している。また、図２５は、セグメント２５３０を示している。セグメント２５３０は、ＥＬＦファイルが含むセクションをリンカーが統合することによって生成されるものであり、．ｉｎｉｔセクションのヘッダ２５１０および／または．ｉｎｉｔ＿ａｒｒａｙセクションのヘッダ２５２０は、ランタイム時に最初に実行され、セグメント２５３０が含むコードセグメント（Ｃｏｄｅ ｓｅｇｍｅｎｔ）２５３１のコードを実行するように実現されてよい。ここで、コードセグメント２５３１は、読み取り−書き取り−実行（Ｒｅａｄ−Ｗｒｉｔｅ−Ｅｘｅｃｕｔｅ：ＲＷＥ）権限を有してよく、データセグメント２５３２は、読み取り−書き取り（Ｒｅａｄ−Ｗｒｉｔｅ：ＲＷ）権限を有してよい。

このようなコードセグメント２５３１は、アプリケーションの駆動のための実際の実行コードを含んでいる。しかし、実行コードに対して難読化がなされた場合（一例として、実行コードのうちの少なくとも一部が暗号化された場合）、正常な方法によってコードセグメント２５３１のコードが実行される場合には、暗号化されたコードによって実行コードが正常に実行されることができない。

したがって、このようなコード難読化の場合には、難読化されたコードを復元するために、読み取り−書き取り−実行（Ｒｅａｄ−Ｗｒｉｔｅ−Ｅｘｅｃｕｔｅ：ＲＷＥ）権限を有する新たなセグメントが挿入されるようになる。図２５の実施形態では、挿入されたセグメント（Ｉｎｓｅｒｔｅｄ ｓｅｇｍｅｎｔ）２５３３に難読化されたコードを復元するための命令が追加される例を示している。このとき、ランタイム時に最初に実行される．ｉｎｉｔセクションのヘッダ２５１０および／または．ｉｎｉｔ＿ａｒｒａｙセクションのヘッダ２５２０は、コードセグメント２５３１ではなく、挿入されたセグメント２５３３をポインティングするように変更されてよい。

このような難読化を探知するための一実施形態において、保安性評価システム３００は、挿入されたセグメント２５３３の存在を探索してよい。このとき、保安性評価システム３００は、読み取り−書き取り−実行（ＲＷＥ）権限を有する挿入されたセグメント２５３３が存在する場合、コードセグメント２５３１に難読化が適用されたものと決定してよい。

他の実施形態において、保安性評価システム３００は、．ｉｎｉｔセクションのヘッダ２５１０および／または．ｉｎｉｔ＿ａｒｒａｙセクションのヘッダ２５２０に挿入されたセグメント２５３３へのポインティングが存在するかを探索してよい。このとき、保安性評価システム３００は、．ｉｎｉｔセクションのヘッダ２５１０および／または．ｉｎｉｔ＿ａｒｒａｙセクションのヘッダ２５２０に挿入されたセグメント２５３３へのポインティングが存在する場合、コードセグメント２５３１に難読化が適用されたものと決定してよい。

また他の実施形態において、保安性評価システム３００は、挿入されたセグメント２５３２を分析（一例として、ディスアセンブル）し、コードセグメント２５３１に含まれた難読化されたコードを復元（一例として、暗号化されたコードを復号）するためのコードが挿入されたセグメント２５３３に存在する場合、コードセグメント２５３１に難読化されたものと決定してよい。

また、保安性評価システム３００は、コード自体を分析することにより、コードに対する難読化の有無を探知してもよい。

図２６は、本発明の一実施形態における、コードの整合性を説明するための例示図である。保安性評価システム３００は、図２４を参照しながら説明したように、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）に含まれるシンボルエントリーテーブル１９２０からエクスポートシンボルエントリー（図２４のエクスポート関数）に基づいて関数のアドレスを収集してよい。このとき、保安性評価システム３００は、収集されたアドレスに基づいてそれぞれの関数が含む命令を分析してよい。

例えば、図２６に示すように、命令ＰｕｓｈとＰｏｐは、アセンブリ語において最も多く使用される命令であり、Ｐｕｓｈ ａ、ｂ ２６１０は、オペランドａ、ｂの値をスタック（レジスタ）に格納するための命令であり、Ｐｏｐ ａ、ｂ ２６２０は、スタック最上端の値を取り出してオペランドａ、ｂに格納する動作のための命令である。したがって、保安性評価システム３００は、図２６に示すように、Ｐｕｓｈされたレジスタの値がＰｏｐになっているかを探索することによってコードの整合性を分析してよい。Ｐｕｓｈされたレジスタの値がＰｏｐになっていなければ、少なくとも一部のコードに難読化が適用されたものと判断してよい。

図２６を参照しながら説明したＰｕｓｈとＰｏｐの他にも、命令ｓｔｍｆｄとｌｄｍｆｄのペア、命令ｓｔｍｄｂとｐｏｐ．ｗのペアにもこのような整合性が求められる。保安性評価システム３００は、このような命令ｓｔｍｆｄとｌｄｍｆｄのペアと命令ｓｔｍｄｂとｐｏｐ．ｗのペアに対する整合性をさらに分析してもよく、命令間に整合性がない場合、少なくとも一部のコードに難読化が適用されたものと判断してよい。

また、保安性評価システム３００は、存在しない（予め定義されていない）演算コード（ｏｐｅｒａｔｉｏｎ ｃｏｄｅ：ｏｐｃｏｄｅ）の組合せが存在するかに応じて、少なくとも一部のコードに対する難読化の適用有無を決定してもよい。言い換えれば、難読化によって演算コードが存在しない組合せを構成するようになる場合、保安性評価システム３００は、コードの難読化を探知してよい。

また、保安性評価システム３００は、分岐（ｂｒａｎｃｈ）コードの分岐位置に関する情報に基づいてコードに対する難読化の適用有無を決定してもよい。例えば、上述したように、保安性評価システム３００は、関数のアドレスに関する情報に基づき関数全体に関する情報を有している。このとき、分岐コードにより、次に実行される命令の位置がこのような関数への位置ではない場合、保安性評価システム３００は、コードの難読化を探知することができる。

図２７は、本発明の一実施形態における、分岐位置に関する情報に基づいてコードに対する難読化の適用有無を決定する例を示した図である。図２７は、関数Ａ（２７００）が含む分岐コード２７１０により、図２５を参照しながら説明したセグメント２５３０のコードセグメント２５３１ではなく、挿入されたセグメント２５３３に分岐する例を示している。この場合、保安性評価システム３００は、少なくとも一部のコードに難読化が適用されていることを探知してよい。

また、保安性評価システム３００は、予め定義されたパターンのダミーコードが存在するかに基づき、バイナリコードに対する難読化の適用有無を決定してもよい。ダミーコードは、レジスタに影響を与えないながらもコード分析を難しくするために追加されるコードであって、一定の形式を有する。したがって、保安性評価システム３００は、このようなダミーコードのパターンに関する情報を予め定義して管理してよく、管理されるパターンのコードが存在する場合にはこれをダミーコードとして判断してよく、コード難読化のためにダミーコードが追加されたことを探知してよい。

以下の表１は、ダミーコードの例を示している。

また、保安性評価システム３００は、ソースコードにダミーコードを追加して難読化してもよい。このようなダミーコードは、コンパイルによってジャンクコード（ｊｕｎｋ ｃｏｄｅ）に変換されてよい。

図２８は、本発明の一実施形態における、ソースコードにダミーコードを追加する例を示した図である。図２８は、演算コード２８１１を含むソースコード２８１０にダミーコード２８２１を追加することで難読化されたソースコード２８２０を生成し、難読化されたソースコード２８２０をコンパイルすることでジャンクコード２８３１とコンパイルされた演算コード２８３２を含むバイナリコード２８３０を生成する例を示している。

このとき、ダミーコード２８２１とジャンクコード２８３１は、一定のパターンを有するようになる。これは、ダミーコード２８２１がコンパイルされることのできる一定の形式を有さなければならない上に、本来の演算コード２８１１やコンパイルされた演算コード２８３２に影響を及ぼしてはいけないからである。したがって、保安性評価システム３００は、このようなダミーコード２８２１および／またはジャンクコード２８３１に対するパターンを予め設定して管理してよく、ソースコードやバイナリコードから予め定義されたパターンが発見される場合、コードに対する難読化の適用を探知してよい。例えば、バイナリコードにおいて、命令ｌｄｒおよび／または命令ｌｓｌｓの連続的な使用がジャンクコード２８３１に対するパターンとして設定されることがある。この場合、保安性評価システム３００は、バイナリコードを分析して命令ｌｄｒおよび／または命令ｌｓｌｓが繰り返し使用されるパターンを探知し、コードに対する難読化の適用を探知してよい。

図２９は、本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第４例を示したブロック図であり、図３０は、本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第４例を示したフローチャートである。

本発明の実施形態に係る保安性評価システム３００は、上述したサーバ１５０のようなコンピュータ装置の形態で実現されてよい。また、図２９に示すように、サーバ１５０のプロセッサ２２２は、保安性評価システム３００を実現するための構成要素として、パッケージファイル登録部２９１０、ＥＬＦファイル識別部２９２０、難読化決定部２９３０、保安性等級決定部２９４０、およびレポート部２９５０を備えてよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図３０の保安性評価方法が含む段階３０１０〜段階３０５０を実行してよい。このとき、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１に含まれるオペレーティングシステムのコードや少なくとも１つのプログラムのコードによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２２の構成要素は、サーバ１５０に格納されたコードが提供する制御命令に従ってプロセッサ２２２によって実行される、プロセッサ２２２の互いに異なる機能の表現であってよい。例えば、プロセッサ２２２が上述した制御命令に従ってパッケージファイルを登録するプロセッサ２２２の機能的表現として、パッケージファイル登録部２９１０が使用されてよい。

段階３０１０において、パッケージファイル登録部２９１０は、アプリケーションのインストールおよび駆動のためのパッケージファイルを登録してよい。パッケージファイルは、アプリケーションの利用者に配布されるためにアプリケーションパブリッシャに登録されてよい。上述したように、保安性評価システム３００は、アプリケーションパブリッシャが登録されるアプリケーションのパッケージファイルを配布するためのサービスを提供する装置で実現されてもよいし、上述した装置とネットワーク１７０を介して通信する別のシステムとして実現されてもよい。例えば、保安性評価システム３００は、アプリケーションパブリッシャに登録されるパッケージファイルを、ネットワーク１７０を介して受信して登録してよい。このようなパッケージファイルは、上述したように、アンドロイドアプリケーションパッケージ（ＡＰＫ）を含んでよい。

段階３０２０において、ＥＬＦファイル識別部２９２０は、登録されたパッケージファイルが含むＥＬＦファイルを識別してよい。一例として、パッケージファイルがアンドロイドアプリケーションパッケージである場合、ＰＥファイルはｓｏファイルであってよい。識別しようとするＥＬＦファイルは、図３を参照しながら説明したように、パッケージ分解モジュール３１０とファイル識別モジュール３２０によって識別されるファイルの中からファイルの拡張子に基づいて識別されてよい。

段階３０３０において、難読化決定部２９３０は、ＥＬＦファイルが含むＥＬＦヘッダ、セクションヘッダ、セクション、およびセグメントのうちの少なくとも１つに対する難読化の適用有無を決定してよい。難読化の適用有無を決定する多様な実施形態については上述したとおりであり、このような実施形態に係る難読化決定部２９３０のより詳しい動作については、以下で図面を参照しながらさらに詳しく説明する。

段階３０４０において、保安性等級決定部２９４０は、難読化の適用有無に基づいてＥＬＦファイルの保安性等級を決定してよい。例えば、ＥＬＦファイルに難読化が適用されているか、ＥＬＦファイルに適用された難読化の種類や程度などに応じてＥＬＦファイルの保安性等級が決定されてよい。難読化の種類は、上述した多様な実施形態を参照しながら詳しく説明したとおりであり、難読化の程度は、一例として、適用された難読化の種類の数、コードの整合性の程度などによって決定されてよい。

段階３０５０において、レポート部２９５０は、難読化の適用有無に関する情報およびＥＬＦファイルに対して決定された保安性等級に関する情報をレポートしてよい。例えば、識別されたＥＬＦファイルに対するセクションヘッダの難読化の適用有無、ストリングおよび／またはストリングテーブルに対する難読化の適用有無、シンボルテーブルに対する難読化の適用有無、コードに対する難読化の適用有無などに関する情報が、保安性評価システム３００の管理者や利用者に提供されてよい。

図３１は、本発明の一実施形態における、ＥＬＦヘッダに対する難読化の適用有無を決定する方法を示したフローチャートである。図３１の段階３１１０〜段階３１３０は、図３０の段階３０３０に含まれてよい。このとき、段階３１１０は段階３０３０に含まれてもよく、段階３０３０以前に実行されてもよい。

段階３１１０において、難読化決定部２９３０は、ＥＬＦヘッダに含まれるセクションヘッダのサイズ、セクションヘッダの数、およびセクションのサイズのうちの少なくとも１つの項目に対する正常値の範囲を設定してよい。

段階３１２０において、難読化決定部２９３０は、ＥＬＦヘッダから少なくとも１つの項目の値を抽出してよい。ＥＬＦヘッダが難読化されていなければ正常値の範囲に含まれる値が抽出されるはずであり、ＥＬＦヘッダが難読化されていれば正常値の範囲を逸脱した値が抽出されるはずである。

段階３１３０において、難読化決定部２９３０は、抽出された値が設定された正常値の範囲を逸脱する場合、ＥＬＦヘッダに難読化が適用されたものと決定してよい。言い換えれば、難読化決定部２９３０は、予めセクションヘッダのサイズ、セクションヘッダの数、およびセクションのサイズのうちの少なくとも１つの項目に対する正常値の範囲を設定しておいた後、ＥＬＦファイルのＥＬＦヘッダに対する難読化の適用有無を判断するために活用してよい。このようなＥＬＦヘッダに対する難読化の探知は、図２３を参照しながら説明したとおりである。

図３２は、本発明の一実施形態における、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）のヘッダに対する難読化の適用有無を決定する方法を示したフローチャートである。図３２の段階３２１０および段階３２２０は、図３０の段階３０３０に含まれてよい。

段階３２１０において、難読化決定部２９３０は、ＥＬＦファイルに含まれるセクションヘッダテーブルから、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）のヘッダを抽出してよい。

段階３２２０において、難読化決定部２９３０は、抽出された動的リンクシンボルテーブルセクションのヘッダを分析してセクションヘッダに対する難読化の適用有無を決定してよい。このために、難読化決定部２９３０は、抽出された動的リンクシンボルテーブルセクションのヘッダがヌル（ｎｕｌｌ）を含むという第１条件、前記抽出された動的リンクシンボルテーブルセクションのヘッダのパース（ｐａｒｓｉｎｇ）が不可能であるという第２条件、および前記抽出された動的リンクシンボルテーブルセクションのヘッダに含まれる情報が、前記セクションのうちの動的リンク情報セクション（．ｄｙｎａｍｉｃセクション）に存在しないという第３条件のうちのいずれか１つの条件が満たされる場合、そのセクションヘッダに難読化が適用されたものと決定してよい。このような動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）のヘッダに対する難読化の探知は、図１９および図２０を参照しながら説明したとおりである。

図３３は、本発明の一実施形態における、実行コードを含むセクションのヘッダに対する難読化の適用有無を決定する方法を示したフローチャートである。図３３の段階３３１０〜段階３３３０は、図３０の段階３０３０に含まれてよい。

段階３３１０において、難読化決定部２９３０は、ＥＬＦファイルが含むセクションのうち、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）に含まれるエクスポートシンボルエントリーに基づいて関数のアドレスを収集してよい。例えば、難読化決定部２９３０は、エクスポートシンボルエントリーのアドレスをディスアセンブルして全体関数を追跡し、そのアドレスを収集してよい。

段階３３２０において、難読化決定部２９３０は、ＥＬＦファイルが含むセクションヘッダテーブルにおいて、実行コードを含むセクション（．ｔｅｘｔセクション）のヘッダから実行コードのサイズに対する値を抽出してよい。実行コードを含むセクション（．ｔｅｘｔセクション）のヘッダが操作（難読化）されているときに抽出される値は、収集されたアドレスに基づいて計算される値とは異なるはずである。

段階３３３０において、難読化決定部２９３０は、収集されたアドレスに基づいて計算される実行コードのサイズと抽出された値を比較し、実行コードを含むセクションのヘッダに対する難読化の適用有無を決定してよい。言い換えれば、計算される値と抽出される値が互いに異なる場合、実行コードを含むセクションのヘッダに対する難読化を探知するようになる。このような実行コードを含むセクションのヘッダに対する難読化の探知については、図２４を参照しながら説明したとおりである。

図３４は、本発明の一実施形態における、動的リンクシンボルテーブルセクションに対する難読化の適用有無を決定する方法を示したフローチャートである。図３４の段階３４１０は、図３０の段階３０３０に含まれてよい。

段階３４１０において、難読化決定部２９３０は、ＥＬＦファイルに含まれるセクションのうち、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）に含まれるシンボルエントリーを分析し、シンボルエントリーに含まれる名称およびアドレスのうちの少なくとも１つがヌルを含むか、またはアスキーコードで表現されていない場合、動的リンクシンボルテーブルセクションに難読化が適用されたものと決定してよい。このような難読化探知の過程については、図２１を参照しながら説明したとおりである。

図３５は、本発明の一実施形態における、読み取り専用セクションに対する難読化の適用有無を決定する方法を示したフローチャートである。図３５の段階３５１０は、図３０の段階３０３０に含まれてよい。

段階３５１０において、難読化決定部２９３０は、ＥＬＦファイルに含まれるセクションのうち、読み取り専用セクションに含まれる情報を分析し、含まれる情報がヌルを含むか、またはアスキーコードで表現されていない場合、読み取り専用セクションに対して難読化が適用されたものと決定してよい。このような読み取り専用セクションは．ｒｄａｔａセクションまたは．ｒｏｄａｔａセクションを含んでよく、このようなセクションに対する難読化の探知については、図２２を参照しながら説明したとおりである。

図３６は、本発明の一実施形態における、コードに対する難読化の適用有無を決定する方法の第１例を示したフローチャートである。図３６の段階３６１０は、図３０の段階３０３０に含まれてよい。

段階３６１０において、難読化決定部２９３０は、ＥＬＦファイルに含まれるセクションがリンカーによって統合されて生成されるように、予め定義されているセグメントの他に、読み取り−書き取り−実行権限を有する他のセグメントが追加されているかに応じて、予め定義されているセグメントに含まれるコードに対する難読化の適用有無を決定してよい。図２５では、挿入されたセグメント２５３３について説明したが、このようなセグメントの挿入自体がコードに難読化が適用されていることを意味してよい。したがって、難読化決定部２９３０は、読み取り−書き取り−実行権限を有する他のセグメントが追加されることを、コードに難読化が適用されたことと解釈してよい。

図３７は、本発明の一実施形態における、コードに対する難読化の適用有無を決定する方法の第２例を示したフローチャートである。図３７の段階３７１０〜段階３７３０は、図３０の段階３０３０に含まれてよい。

段階３７１０において、難読化決定部２９３０は、ＥＬＦファイルが含むセクションがリンカーによって統合されて生成されるように、予め定義されているセグメントの他に、読み取り−書き取り−実行（ＲＷＥ）権限を有する他のセグメントの追加を確認してよい。

段階３７２０において、難読化決定部２９３０は、ＥＬＦファイルに含まれるセクションヘッダテーブルにおいて、プロセス初期化のためのコードを含むセクション（．ｉｎｉｔセクションまたは．ｉｎｉｔ＿ａｒｒａｙセクション）のヘッダを識別してよい。

段階３７３０において、難読化決定部２９３０は、識別されたセクションのヘッダで確認された他のセグメントへのポインティングが存在する場合、予め定義されているセグメントに含まれるコードに難読化が適用されたものと決定してよい。

図２５で説明したように、コードが難読化される場合、難読化されたコードを復元するためのコードが求められるようになり、このようなコードを追加するためのセグメントが挿入されるようになる。また、ランタイム時に最初に実行されるプロセス初期化のためのコードを含むセクション（．ｉｎｉｔセクションまたは．ｉｎｉｔ＿ａｒｒａｙセクション）のヘッダは、難読化されたコードを復元するために、挿入されたセグメントをポインティングするようになる。したがって、難読化決定部２９３０は．ｉｎｉｔセクションまたは．ｉｎｉｔ＿ａｒｒａｙセクションが挿入されたセグメントのポインティングを探知し、これを予め定義されているセグメント（一例として、図２５のコードセグメント２５３１）に含まれるコードに対する難読化として探知してよい。

図３８は、本発明の一実施形態における、コードに対する難読化の適用有無を決定する方法の第３例を示したフローチャートである。図３８の段階３８１０および段階３８２０は、図３０の段階３０３０に含まれてよい。

段階３８１０において、難読化決定部２９３０は、ＥＬＦファイルに含まれるセクションがリンカーによって統合されて生成されるように、予め定義されているセグメントの他に、読み取り−書き取り−実行（ＲＷＥ）権限を有する他のセグメントの追加を確認してよい。

段階３８２０において、難読化決定部２９３０は、確認された他のセグメントを分析し、アプリケーションのランタイム時に暗号化されたコードを復元するためのコードが存在する場合、予め定義されているセグメントに含まれたコードに難読化が適用されたものと決定してよい。

上述したように、コードが難読化される場合、難読化されたコードを復元するためのコードが求められるようになり、このようなコードを追加するためのセグメントが挿入されるようになる。したがって、難読化決定部２９３０は、このような挿入されたセグメントを分析して暗号化されたコードを復元するためのコードが存在するか確認し、このようなコードの存在を予め定義されているセグメント（一例として、図２５のコードセグメント２５３１）に含まれたコードの難読化として探知してよい。

図３９は、本発明の一実施形態における、命令を分析してコードに対する難読化の適用有無を決定する方法を示したフローチャートである。図３９の段階３９１０および段階３９２０は、図３０の段階３０３０に含まれてよい。

段階３９１０において、難読化決定部２９３０は、ＥＬＦファイルが含むセクションのうち、動的リンクシンボルテーブルセクション（．ｄｙｎｓｙｍセクション）に含まれたエクスポートシンボルエントリーに基づいて関数のアドレスを収集してよい。

段階３９２０において、難読化決定部２９３０は、収集されたアドレスを利用して関数が含む命令を分析し、コードに対する難読化の適用有無を決定してよい。

このとき、難読化決定部２９３０は、関数に含まれる命令間の整合性、定義されていない演算コードの組合せの存在有無、分岐コードの分岐位置に関する情報、および予め定義されたパターンのダミーコードの存在有無のうちの少なくとも１つに基づき、コードに対する難読化の適用有無を決定してよい。

例えば、難読化決定部２９３０は、段階３９２０において、ＥＬＦファイルに含まれるセクションがリンカーによって統合されて生成されるように、予め定義されているセグメントの他に、読み取り−書き取り−実行（ＲＷＥ）権限を有する他のセグメントの追加を確認し、関数に含まれる命令が、他のセグメントに含まれるコードに分岐する場合、コードに難読化が適用されたものと決定してよい。

図３１〜図３９の段階は、段階３０３０内でそれぞれ互いに並列的に実行されてよい。また、このような段階が互いに並列的に実行されるにあたり、同じ動作を実行する段階は重複して実行されず、１度だけ実行されてよい。例えば、関数のアドレスを収集する段階３３１０と段階３９１０は、２つのうちの１つの段階だけが実行されてもよい。

図４０は、本発明の一実施形態における、登録されたパッケージファイルに含まれるＰＥファイルの例を示した図である。保安性評価システム３００に登録されたパッケージファイルには、難読化が適用された状態のＰＥファイルまたは難読化が適用されていないＰＥファイルが含まれてよい。このとき、保安性評価システム３００は、このようなパッケージファイルに含まれるＰＥファイルに難読化が適用されているかを決定してよい。ＰＥファイルの構造は周知のとおりであるため、別途説明しなくても、当業者であれば容易に理解することができるであろう。一例として、登録されたパッケージファイルのＰＥファイルとして、アンドロイドアプリケーションパッケージ（ＡＰＫ）に含まれるＤＬＬが含まれてよい。

このとき、図４０の実施形態では、難読化が適用されていない第１ＰＥファイル４０１０と、ファイルに含まれた全体バイナリを暗号化することで難読化が適用された第２ＰＥファイル４０２０の例を示している。例えば、登録されたパッケージファイルが第２ＰＥファイル４０２０を含んでいる場合、登録されたパッケージファイルは、このような第２ＰＥファイル４０２０で暗号化された情報を復号するための情報が、他のファイルにさらに含まれていることがある。このとき、パッケージファイルに基づいて電子機器（一例として、電子機器１（１１０））にアプリケーションがインストールされて駆動される場合、第２ＰＥファイル４０２０の暗号化された情報が、他のファイルに含まれる復号情報によって復号されることにより、アプリケーションが正常に実行されるようになる。

図４１は、本発明の一実施形態における、全体バイナリが暗号化されたＰＥファイルに対する難読化の適用有無を決定する過程の例を示した図である。図４０を参照しながら説明した第２ＰＥファイル４０２０のように、全体バイナリが暗号化されている場合には、第２ＰＥファイル４０２０から正常値（一例として、ＰＥファイルのヘッダに常に含まれる一定の値）を抽出することができない。例えば、一般的なＰＥファイルのヘッダが、Ｄｏｓヘッダ、Ｄｏｓスタブ、ＰＥヘッダ、およびセクションテーブルで実現されているとする。このとき、Ｄｏｓヘッダは、合計６４ｂｙｔｅで構成され、最初の部分はＭＺというＤｏｓヘッダのシグニチュア（ｓｉｇｎａｔｕｒｅ）から始まるように予め定義されている。したがって、保安性評価システム３００は、Ｄｏｓヘッダからシグニチュアの抽出を試した結果、予め定義されている一定の値であるＭＺが抽出されない場合は、該当のＰＥファイルが難読化されていることが分かる。また．Ｎｅｔヘッダでは、ＢＳＪＢというシグニチュアが活用されたりもする。

このとき、図４１の実施形態では、保安性評価システム３００が、図４０を参照しながら説明したように、第２ＰＥファイル４０２０のヘッダからシグニチュアの抽出を試した例を示している。このとき、第２ＰＥファイル４０２０は、全体バイナリが暗号化（または難読化）されているため、所望するシグニチュアの抽出が行われない。したがって、保安性評価システム３００は、第２ＰＥファイル４０２０に難読化が適用されていることを確認できるようになる。

実施形態によっては、保安性評価システム３００は、互いに異なる複数のシグニチュアの抽出を試してみてもよい。このとき、抽出が試されたシグニチュアそれぞれの抽出の有無に応じて点数が付与されてよく、このような点数に基づいてＰＥファイルの保安性に対する危険等級が設定されてよい。この場合、点数が低いほどＰＥファイルの保安性は高くてよく、これとは逆に危険等級は低く設定されてよい。例えば、Ｄｏｓヘッダのシグニチュアは抽出されないが、．Ｎｅｔヘッダのシグニチュアが抽出される場合、ＰＥファイルの全体バイナリのうちの一部だけに暗号化（または難読化）が適用されているものと決定されてよく、このような場合、全体バイナリを暗号化（または難読化）したものよりも、保安性は相対的に低く、危険等級は高く設定されてよい。

一方、実行コードで特定のクラスや特定のメソッドのみを指定して暗号化する方式によって難読化がＰＥファイルに適用されてもよい。このような実行コードは、図４０に示された「．ｔｅｘｔ」セクションに含まれてよい。

図４２は、本発明の一実施形態における、特定のクラスや特定のメソッドが暗号化されたＰＥファイルの例を示した図である。図４２は、ＰＥファイル４２１０のテキストセクション（．ｔｅｘｔ）４２２０で特定のメソッドが暗号化されることにより暗号化されたコード４２３０を含む例を示している。保安性評価システム３００は、このような暗号化による難読化がＰＥファイル４２１０に適用されているか分からないため、このような難読化の適用有無を決定するための過程が実施される必要がある。

保安性評価システム３００は、ＰＥファイル４２１０にどのようなクラスとメソッドが存在するか分からないため、優先的にＰＥファイル２１０が含むメタデータテーブルをパースして分析してよい。一例として、保安性評価システム３００は．Ｎｅｔ２．０に含まれる合計４２個のメタデータテーブルのうち、「ＭｅｔｈｏｄＤｅｆ」テーブル、「ＭｏｄｕｌｅＲｅｆ」テーブル、「ＴｙｐｅＲｅｆ」テーブル、および「ＴｙｐｅＤｅｆ」テーブルをパース／分析してクラスリストを確保してよく、クラスとメソッドをマッピングしてよい。すなわち、保安性評価システム３００は、このようなメタデータテーブルを分析する過程により、ＰＥファイル４２１０にはどのようなクラスが存在し、またそれぞれのクラスにどのようなメソッドが含まれているかを把握できるようになる。

したがって、保安性評価システム３００は、全体メソッドを把握できるようになり、このような全体メソッドそれぞれに対して暗号化（または難読化）が適用されているかを決定することができる。このために、保安性評価システム３００は、メソッドの仮想メモリにおける相手のアドレス値を意味する相対仮想アドレス（ＲＶＡ：Ｒｅｌａｔｉｖｅ Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ）を求め、テキストセクション４２２０からメソッドの本体命令（ｂｏｄｙ ｉｎｓｔｒｕｃｔｉｏｎ）を抽出してよい。

このとき、保安性評価システム３００は、抽出された本体命令が含む命令演算コード（ｏｐｃｏｄｅ）の整合性を分析し、抽出された本体命令に対応するメソッドに対する難読化の適用有無を決定してよい。

ここで、命令には、１ｂｙｔｅ命令と２ｂｙｔｅ命令が存在し、このような命令をパースするための従来の方式が存在する。例えば、このような従来の方式では、メソッドのパースのために本体命令から１ｂｙｔｅのデータを読み取り、その値が「０ｘ００〜０ｘＥ０」の範囲に含まれる場合は、読み取った１ｂｙｔｅのデータが１ｂｙｔｅ命令であることが分かる。その値が「０ｘ００〜０ｘＥ０」の範囲に含まれなければ、２ｂｙｔｅのデータを読み取り、１番目のｂｙｔｅの値がＯｘＦＥであり、２番目のｂｙｔｅの値が「０ｘ００〜０ｘ１Ｅ」の範囲に含まれるかを確認してよい。このとき、１番目のｂｙｔｅの値が０ｘＦＥであり、２番目のｂｙｔｅの値が「０ｘ００〜０ｘ１Ｅ」の範囲に含まれる場合、読み取った２ｂｙｔｅのデータが２ｂｙｔｅ命令であることが分かる。また、従来の方式では、それぞれの命令に適合する追加演算コードを分析することにより、次の命令を求めることができた。例えば、１ｂｙｔｅの命令であり、「ｉｎｔ３２ ｔｙｐｅ」の命令であれば、次の命令は５ｂｙｔｅ（１ｂｙｔｅ＋４ｂｙｔｅ（３２ｂｉｔ））以後の位置で得られるようになる。

しかし、メソッドが暗号化されていれば、このような方式では命令を得ることはできない。したがって、保安性評価システム３００は、抽出された本体命令に対して一般的なパース作業を実施し、少なくとも１つの命令に対して正常なパース作業がなされていない場合、該当のメソッドに対して難読化が適用されたことを把握できるようになる。

このとき、保安性評価システム３００は、全体メソッドそれぞれに対してこのようなパース作業を実施し、全体メソッドのうちから難読化が適用されたメソッドを判断できるようになる。この場合、保安性評価システム３００は、全体メソッドのうちで難読化が適用されたメソッドの割合に基づいてＰＥファイル４２１０の保安性等級を決定してよい。

図４３は、本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の第５例を示したブロック図であり、図４４は、本発明の一実施形態における、サーバが実行することのできる保安性評価方法の第５例を示したフローチャートである。

本発明の実施形態に係る保安性評価システム３００は、上述したサーバ１５０のようなコンピュータ装置の形態で実現されてよい。また、図４３に示すように、サーバ１５０のプロセッサ２２２は、保安性評価システム３００を実現するための構成要素として、パッケージファイル登録部４３１０、ＰＥファイル識別部４３２０、本体命令抽出部４３３０、難読化決定部４３４０、保安性決定部４３５０、および情報提供部４３６０を備えてよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図４４の保安性評価方法に含まれる段階４４１０〜段階４４６０を実行してよい。このとき、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１に含まれるオペレーティングシステムのコードや少なくとも１つのプログラムのコードによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２２の構成要素は、サーバ１５０に格納されたコードが提供する制御命令に従ってプロセッサ２２２によって実行される、プロセッサ２２２の互いに異なる機能の表現であってよい。例えば、プロセッサ２２２が上述した制御命令に従ってパッケージファイルを登録するプロセッサ２２２の機能的表現として、パッケージファイル登録部４３１０が使用されてよい。

段階４４１０において、パッケージファイル登録部４３１０は、アプリケーションのインストールおよび駆動のためのパッケージファイルを登録してよい。パッケージファイルは、アプリケーションの利用者に配布されるためにアプリケーションパブリッシャに登録されてよい。上述したように、保安性評価システム３００は、アプリケーションパブリッシャが登録されるアプリケーションのパッケージファイルを配布するためのサービスを提供する装置で実現されてもよいし、上述した装置とネットワーク１７０を介して通信する別のシステムとして実現されてもよい。例えば、保安性評価システム３００は、アプリケーションパブリッシャに登録されるパッケージファイルを、ネットワーク１７０を介して受信して登録してもよい。このようなパッケージファイルは、上述したように、アンドロイドアプリケーションパッケージ（ＡＰＫ）を含んでよい。

段階４４２０において、ＰＥファイル識別部４３２０は、登録されたパッケージファイルに含まれるＰＥファイルを識別してよい。一例として、パッケージファイルがアンドロイドアプリケーションパッケージである場合、ＰＥファイルはＤＬＬファイルであってよい。識別しようとするＰＥファイルは、図３を参照しながら説明したように、パッケージ分解モジュール３１０とファイル識別モジュール３２０で識別されるファイルの中からファイルの拡張子に基づいて識別されてよい。

段階４４３０において、本体命令抽出部４３３０は、ＰＥファイルが含むメタデータテーブル（Ｍｅｔａｄａｔａ Ｔａｂｌｅ）を利用し、ＰＥファイルが含むテキストセクションからメソッドの本体命令を抽出してよい。上述したように、本体命令抽出部４３３０は、先ず、ＰＥファイルのテキストセクションに含まれたクラスとメソッドを認識し、その後にそれぞれのメソッドのためのＲＶＡを求め、テキストセクションから必要なメソッドの本体命令を抽出してよい。

段階４４４０において、難読化決定部４３４０は、抽出された本体命令を分析してメソッドに対する難読化の適用有無を決定してよい。上述したように、抽出された本体命令に対等するメソッドに対する難読化の適用有無は、抽出された本体命令が含む命令演算コード（ｏｐｃｏｄｅ）の整合性を分析して決定されてよい。このような難読化の適用有無は、識別される全体メソッドに対してそれぞれ決定されてよい。

段階４４５０において、保安性決定部４３５０は、難読化の適用有無に基づき、パッケージファイルおよびＰＥファイルのうちの少なくとも１つに対する保安性等級を決定してよい。例えば、保安性決定部４３５０は、テキストセクションに含まれる全体メソッドのうち、難読化が適用されたものと決定されたメソッドの割合に基づいて保安性等級（または危険等級）を決定してよい。このとき、前記の割合が高くなるほど相対的に保安性等級は高くなってよく、これとは逆に危険等級は低くなってよい。

段階４４６０において、情報提供部４３６０は、難読化の適用有無に関する情報および決定された保安性等級に関する情報をレポートしてよい。例えば、識別されたＰＥファイルに対し、メソッドに対する難読化が適用されているか、全体クラスの数、難読化が適用されたクラスの数、全体メソッドの数、難読化が適用されたメソッドの数、前記の割合、保安性等級（または危険等級）のような情報が、保安性評価システム３００の管理者や利用者に提供されてよい。

図４５は、本発明の一実施形態における、本体命令を抽出する方法の例を示したフローチャートである。図４５の段階４５１０〜段階４５３０は、図４４を参照しながら説明した段階４４３０に含まれ、本体命令抽出部４３３０によって実行されてよい。

段階４５１０において、本体命令抽出部４３３０は、メタデータテーブルをパースしてクラスリストを取得してよい。一例として、上述したように、保安性評価システム３００は．Ｎｅｔ２．０に含まれる合計４２個のメタデータテーブルのうち、「ＭｅｔｈｏｄＤｅｆ」テーブル、「ＭｏｄｕｌｅＲｅｆ」テーブル、「ＴｙｐｅＲｅｆ」テーブル、および「ＴｙｐｅＤｅｆ」テーブルをパース／分析してクラスリストを確保してよく、クラスとメソッドをマッピングしてよい。このとき、ＰＥファイルで、クラスとメソッドに関する情報がＰＥファイルのヘッダにメタデータテーブルの形態で含まれることは自明であり、本体命令抽出部４３３０は、ＰＥファイルの形態や構造に応じてＰＥファイルのヘッダに含まれた情報を適切に活用しながらクラスとメソッドに関する情報を取得できることは、当業者であれば容易に理解することができるであろう。

段階４５２０において、本体命令抽出部４３３０は、クラスリストを基盤としてクラスとメソッドをマッピングしてよい。例えば、クラスＡがメソッドａ、メソッドｂ、メソッドｃを含んでいる場合、本体命令抽出部４３３０は、このようなクラスＡとメソッドａ、メソッドｂ、メソッドｃをマッピングしてよい。メソッドａ、メソッドｂ、およびメソッドｃがすべて難読化（または暗号化）されている場合、クラスＡに難読化（または暗号化）が適用されたものと解釈されてよい。上述した難読化されたクラスの数は、このような解釈に基づいて決定されてよい。

段階４５３０において、本体命令抽出部４３３０は、ＰＥファイルのヘッダをパースし、マッピングされたメソッドそれぞれの本体命令を抽出してよい。このような本体命令の抽出は、メソッドの仮想メモリにおける相手のアドレス値を意味するＲＶＡに基づき、テキストセクションから該当のメソッドを探索することによって処理されてよい。

図４６は、本発明の一実施形態における、ＰＥファイルに対する難読化の適用有無を決定する例を示した図である。図４０および図４１を参照しながら、ＰＥファイルの全体バイナリが難読化（または暗号化）された例について説明した。例えば．ＮｅｔファイルのようなＰＥファイルは、ＥＬＦファイルとは異なり、リンカーによってロードされず、モノファイル（一例として、ｍｏｎｏ．ｓｏファイル）によってロードされるため、全体ファイルを暗号化して難読化することが可能である。図４６の実施形態では、段階４６１０が図４４を参照しながら説明した段階４４２０と段階４４３０の間に実行される実施形態を示しているが、段階４６１０は、段階４４２０以後に他の段階と並列的に実行されてもよい。また、段階４４１０、段階４４２０、および段階４６１０を含む他の実施形態の保安性評価方法が実現されてもよい。

段階４６１０において、難読化決定部４３４０は、ＰＥファイルのヘッダからシグニチュアの抽出を試した結果、シグニチュアが抽出されない場合、ＰＥファイルに対して難読化が適用されたものと決定してよい。ＰＥファイルの全体バイナリに対して難読化（または暗号化）がなされた場合、シグニチュアは抽出されることができない。したがって、難読化決定部４３４０は、このようなシグニチュアの抽出可否のような簡単な方法により、ＰＥファイルに対する難読化の適用有無を決定できるようになる。また、上述したように、予め定義されている多数のシグニチュアに対する抽出を試し、抽出されるシグニチュアそれぞれに対する点数化によって保安性等級や危険等級を設定して提供してもよい。

以上のように、本発明の実施形態によると、アプリケーションパブリッシャの観点において、登録されるアプリケーションに適用された保安水準を難読化、脆弱性、および保安ソリューションそれぞれの観点によって客観的な方法で分析および把握し、分析された情報を提供してアプリケーションの保安性向上のために活用することができる。また、アンドロイドアプリケーションパッケージ（ＡＰＫ）に含まれるＤｅｘファイルに対する難読化の適用有無を決定することができる。また、ＥＬＦファイルに対する難読化の適用有無を探知することができる。さらに、ＤＬＬのようなＰＥファイルに対する難読化の適用有無を探知することができる。

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

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

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

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

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

２２２：プロセッサ
１０１０：観点別パターン情報格納部
１０２０：パッケージファイル登録部
１０３０：分析情報生成部
１０４０：分析情報提供部
１０５０：追加パターン情報処理部

Claims (20)

1. アプリケーションの保安性を評価する方法であって、
   パッケージファイルを難読化観点および脆弱性観点によって分析するための観点別パターン情報を格納する段階、
   アプリケーションのインストールおよび駆動のために利用者に配布するためのパッケージファイルの登録を受ける段階、
   前記登録されたパッケージファイルを前記観点別パターン情報に基づいて分析し、難読化観点の分析情報および脆弱性観点の分析情報を生成する段階、
   前記生成された分析情報を提供する段階、
   を含むことを特徴とする、保安性評価方法。
2. 前記観点別パターン情報のうちの難読化観点のパターン情報は、前記登録されたパッケージファイルに含まれるファイルのうち、難読化観点によって識別されたファイルから項目別難読化の適用有無を識別するためのパターン情報を含むことを特徴とする、請求項１に記載の保安性評価方法。
3. 前記項目別難読化の適用有無は、前記難読化観点によって識別されたファイルに含まれるメソッドとクラスそれぞれに対する難読化の適用有無を含み、
   前記生成する段階は、
   前記難読化観点のパターン情報に基づいて前記難読化観点によって識別されたファイルから難読化が適用されたメソッドおよびクラスを識別し、対象ファイル別に、（１）難読化が適用されたメソッドの数、（２）難読化が適用されたクラスの数、（３）前記難読化が適用されたメソッドの数および前記難読化が適用されたクラスの数に基づいて決定される危険等級を含む難読化観点の分析情報を生成することを特徴とする、請求項２に記載の保安性評価方法。
4. 前記項目別難読化の適用有無は、前記難読化観点で識別されたファイルに含まれるセクションヘッダ、ストリング、ストリングテーブル、シンボルテーブル、およびコードのうちの少なくとも１つの項目に対応する情報それぞれに対する難読化の適用有無を含み、
   前記生成する段階は、
   前記難読化観点のパターン情報に基づいて前記難読化観点によって識別されたファイルから難読化が適用された項目を識別し、対象ファイル別に、（１）難読化が適用された項目の種類、および（２）前記難読化が適用された項目の種類に基づいて決定される危険等級を含む難読化観点の分析情報を生成することを特徴とする、請求項２に記載の保安性評価方法。
5. 前記生成する段階は、
   前記登録されたパッケージファイルを分解して前記パッケージファイルに含まれるファイルを識別する段階、および
   該識別されたファイルの拡張子に基づいて分析が求められるファイルを観点別に識別し、観点別に識別されたファイルごとに対応する観点の分析情報を生成する段階
   を含むことを特徴とする、請求項１に記載の保安性評価方法。
6. 前記パッケージファイルに含まれるファイル間の参照関係に関する分析情報をさらに生成する段階
   をさらに含み、
   前記提供する段階は、
   前記参照関係に関する分析情報をさらに提供することを特徴とする、請求項５に記載の保安性評価方法。
7. 前記パッケージファイルは、アンドロイドアプリケーションパッケージ（ＡＰＫ）を含み、
   前記生成する段階は、
   前記アンドロイドアプリケーションパッケージが含むＤｅｘファイルからアプリケーションクラスを検索する段階、
   前記アプリケーションクラスに含まれるメソッドの本体命令で呼び出されるクラスおよびメソッドに基づき、前記アンドロイドアプリケーションパッケージにさらに含まれる他のＤｅｘファイルをロードするためのＡＰＩコールの有無を確認する段階、および
   前記他のＤｅｘファイルをロードするためのＡＰＩコールが存在することが確認された場合、前記Ｄｅｘファイルに難読化が適用されているものと決定する段階
   を含むことを特徴とする、請求項１に記載の保安性評価方法。
8. 前記アプリケーションクラスを検索する段階は、
   前記アンドロイドアプリケーションパッケージに含まれるアンドロイドマニフェストファイルから前記アプリケーションクラスのクラス名を抽出し、前記抽出されたクラス名に基づいて前記Ｄｅｘファイルから前記アプリケーションクラスを識別することを特徴とする、請求項７に記載の保安性評価方法。
9. 前記他のＤｅｘファイルをロードするためのＡＰＩコールの有無を確認する段階は、
   前記アプリケーションクラスに含まれるメソッドの本体命令のすべての呼び出しに対する呼び出しリストを生成し、前記生成された呼び出しリストからクラスローダクラスおよびロードクラスメソッドの呼び出しの有無を検索することを特徴とする、請求項７に記載の保安性評価方法。
10. 前記生成する段階は、
    前記登録されたパッケージファイルに含まれるＥＬＦファイルを識別する段階、
    前記ＥＬＦファイルに含まれるＥＬＦヘッダ、セクションヘッダ、セクション、およびセグメントのうちの少なくとも１つに対する難読化の適用有無を決定する段階、および
    前記難読化の適用有無に基づいて前記ＥＬＦファイルの保安性等級を決定する段階
    を含むことを特徴とする、請求項１に記載の保安性評価方法。
11. 前記生成する段階は、
    前記ＥＬＦヘッダが含むセクションヘッダのサイズ、セクションヘッダの数、およびセクションのサイズのうちの少なくとも１つの項目に対する正常値の範囲を設定する段階
    をさらに含み、
    前記難読化の適用有無を決定する段階は、
    前記ＥＬＦヘッダから前記少なくとも１つの項目の値を抽出する段階、および
    前記抽出された値が前記設定された正常値の範囲を逸脱する場合、前記ＥＬＦヘッダに難読化が適用されたものと決定することを特徴とする、請求項１０に記載の保安性評価方法。
12. 前記難読化の適用有無を決定する段階は、
    前記ＥＬＦファイルに含まれるセクションのうち、動的リンクシンボルテーブルセクションに含まれるエクスポートシンボルエントリーに基づいて関数のアドレスを収集する段階、
    前記ＥＬＦファイルに含まれるセクションヘッダテーブルにおいて、実行コードが含まれるセクションのヘッダから実行コードのサイズに対する値を抽出する段階、および
    前記収集されたアドレスに基づいて計算される実行コードのサイズと前記抽出された値を比較し、前記実行コードを含むセクションのヘッダに対する難読化の適用有無を決定する段階
    を含むことを特徴とする、請求項１０に記載の保安性評価方法。
13. 前記生成する段階は、
    前記登録されたパッケージファイルに含まれるＰＥファイルを識別する段階、
    前記ＰＥファイルに含まれるメタデータテーブルを利用して、前記ＰＥファイルが含むテキストセクションからメソッドの本体命令を抽出する段階、および
    前記抽出された本体命令を分析して前記メソッドに対する難読化の適用有無を決定する段階
    を含むことを特徴とする、請求項１に記載の保安性評価方法。
14. 前記テキストセクションからメソッドの本体命令を抽出する段階は、
    前記メタデータテーブルをパースしてクラスリストを取得する段階、
    前記クラスリストに基づいてクラスとメソッドをマッピングする段階、および
    前記ＰＥファイルのヘッダをパースして前記マッピングされたメソッドそれぞれの本体命令を抽出する段階
    を含むことを特徴とする、請求項１３に記載の保安性評価方法。
15. 前記メソッドに対する難読化の適用有無を決定する段階は、
    前記抽出されたバディ命令が含む命令演算コード（ｏｐｃｏｄｅ）の整合性を分析し、前記抽出された命令に対応するメソッドに対する難読化の適用有無を決定することを特徴とする、請求項１３に記載の保安性評価方法。
16. 請求項１〜１５のうちのいずれか一項に記載の方法をコンピュータに実行させるためのコンピュータプログラムが記録されていることを特徴とする、コンピュータ読取可能な記録媒体。
17. アプリケーションの保安性を評価するシステムであって、
    コンピュータ読取可能な命令を実行するように実現される少なくとも１つのプロセッサ
    を含み、
    前記少なくとも１つのプロセッサは、
    パッケージファイルを難読化観点および脆弱性観点によって分析するための観点別パターン情報を格納し、
    アプリケーションのインストールおよび駆動のために利用者に配布するためのパッケージファイルの登録を受け、
    前記登録されたパッケージファイルを前記観点別パターン情報に基づいて分析して難読化観点の分析情報および脆弱性観点の分析情報を生成し、
    前記生成された分析情報を提供すること
    を特徴とする、保安性評価システム。
18. 前記パッケージファイルは、アンドロイドアプリケーションパッケージ（ＡＰＫ）を含み、
    前記少なくとも１つのプロセッサは、
    前記アンドロイドアプリケーションパッケージに含まれるＤｅｘファイルからアプリケーションクラスを検索し、
    前記アプリケーションクラスに含まれるメソッドの本体命令で呼び出されるクラスおよびメソッドに基づき、前記アンドロイドアプリケーションパッケージにさらに含まれる他のＤｅｘファイルをロードするためのＡＰＩコールの有無を確認し、
    前記他のＤｅｘファイルをロードするためのＡＰＩコールが存在するものと確認される場合、前記Ｄｅｘファイルに難読化が適用されたものと決定すること
    を特徴とする、請求項１７に記載の保安性評価システム。
19. 前記少なくとも１つのプロセッサは、
    前記登録されたパッケージファイルに含まれるＥＬＦファイルを識別し、
    前記ＥＬＦファイルに含まれるＥＬＦヘッダ、セクションヘッダ、セクションおよびセグメントのうちの少なくとも１つに対する難読化の適用有無を決定し、
    前記難読化の適用有無に基づいて前記ＥＬＦファイルの保安性等級を決定すること
    を特徴とする、請求項１７に記載の保安性評価システム。
20. 前記少なくとも１つのプロセッサは、
    前記登録されたパッケージファイルに含まれるＰＥファイルを識別し、前記ＰＥファイルに含まれるメタデータテーブルを利用して前記ＰＥファイルに含まれるテキストセクションからメソッドの本体命令を抽出し、
    前記抽出された本体命令を分析して前記メソッドに対する難読化の適用有無を決定すること
    を特徴とする、請求項１７に記載の保安性評価システム。

Images