JP6346632B2 - モバイルデバイスでの悪質なファイルを検出するシステム及び方法 - Google Patents

Description

本出願は、米国特許法35 U.S.C. 119(a)-(d)に基づいて、2015年6月30日に出願されたロシア特許出願第2015125969についての優先権の利益を主張し、本明細書中に援用する。

本開示は、一般的にコンピュータセキュリティの分野に関連し、より具体的には、モバイルデバイスでの悪質なファイルを検出するシステム及び方法に関連するものである。

モバイルコンピューティングデバイス（以下、モバイルデバイス）は、現代社会における生活の不可欠な一部となっている。このようなデバイスの例は、携帯電話、スマートフォン、パーソナルコミュニケーター、タブレットコンピュータ又はノートブックである。大多数のモバイルデバイスは、一般的に、日常のルーチンに必要なさまざまなユーザのデータを含んでいる。そのようなデータは、プライベートデータ（例えば、写真、ビデオなど）、パーソナルデータ（例えば氏名、生年、電話番号など）、および機密データ（銀行サイト、クレジットカード番号へのログイン又はパスワードなど）等のデータであってもよい。

モバイルデバイスで使用される最も人気のあるモバイルプラットフォームの一つは、オペレーティングシステムGoogle Android（Android OS）である。第一に、Android OSは、そのオープン且つフリーな性質のために、その人気を獲得し、さまざまなハードウェアプラットフォームで幅広く使用され、且つ、結果として、膨大な数の異なるアプリケーションが、Android OSで作業したい人々によって開発された。現在では、数百万のアプリケーションが既にAndroid OSのために作成されており、世界中で10億を超える多くのモバイルデバイスにインストールされている。同時に、さらに多くの悪質なプログラムが、Android OSを使用しているモバイルデバイス用に作成された。”モバイルデバイス用の悪質なプログラム”という用語は、一般的に、モバイルデバイスのコンピューティング・リソース又はそこに格納されている情報への不正アクセス得るために設計された任意のソフトウェアを含むものであり、それは、情報をコピー、歪める、削除、又は、交換することにより、リソースの不正使用又はモバイルデバイスの所有者に害を与える（損失を引き起こす）という目的を持つものである。”情報”という用語は、一般的に、様々なアプリケーション又はWebサイトへのアクセスができるユーザの連絡先又はクレジットカードに関する情報を含むものである。”不正使用”という用語は、一般的に、モバイルデバイスの所有者の認可及び/又は所有者が知ることなく実行されるアクション（不要な電子決済の支払いの作成、スパムを含む電子メールの送信、電話発信等）を含むものである。したがって、モバイルデバイスにインストールされているアプリケーションは、多かれ少なかれ、ユーザの”重要”なデータにアクセスする権利を持っており、悪質なプログラムに対して、モバイルデバイス及びそれらのアプリケーションを保護することが重要になってきている。

モバイルデバイスを保護するための既存の解決策の主要なものとしては、Windowsオペレーティングシステムを使用しているパソコンのアンチウィルスプログラムを原則的に適応するものである。それをモバイルデバイスで使用する場合、このようなアンチウィルスプログラムには、多くの難しい問題が生じる。第一に、悪質なアクションは、モバイルデバイスとPCでは異なっており、それに対応するように、アンチウィルスプログラムの技術を適応することが必要となってくる。第二に、悪質なプログラムによって実行されているモバイルデバイスアクションは、一般的に、API関数によって実現され、各モバイルプラットフォーム（例えば、Linux（登録商標）カーネルのOS、AndroidのOS、AppleのOS（IOS）又はBada OS）はそれ自身のAPI関数を有しているので、最適化は、また、各プラットフォームのために対応する必要があり、それは、アンチウィルスプログラムの動作を複雑にすることになる。したがって、悪質なファイルを探し出して、アンチウィルスチェックを行う場合、これについても考慮されなければならない。第三に、モバイルデバイス用に意図されたアンチウィルスプログラムは、バッテリ、中央処理装置（CPU）、メモリ等のモバイルデバイスのシステムリソースの使用には限界がある（例えば、OS自体がリソースへのアクセスを制限する）。これらの難しい問題の解決のために、モバイルプラットフォームの特別な機能を考慮した専用のアンチウィルスプログラムが必要となる。

さらに、悪質なプログラムは、まだ居座っていない。現段階では、モバイルプラットフォームのためのより多くのプログラムがあり、特にトロイの木馬プログラムがある。トロイの木馬は、多様性の技術（実際の機能を変えることなく、ファイルに追加/変更の命令する技術）、変成の技術（その機能性を変えることなく、ウイルス本体を完全に変化し、多様性におけるより複雑な形状にする技術）、及びプログラムコードを難読化する技術を用いている。難読化とは、オリジナルテキスト又はプログラムの実行コードを、その機能性の形態を保ったまま変化させるが、解析すること、動作アルゴリズムを理解すること、及び、逆コンパイルに対して抵抗することを意味する。これらの技術により、マルウェアの実行可能コードを非表示にし、コードの機能を保っている形式のまま変化することができるが、アンチウィルスの解析に抵抗し、そのアルゴリズムの動作を隠すことができる。

また、Android OSであるモバイル・アプリケーションの実行における主要な技術の一つは、Dalvik仮想マシンである。Dalvik実行フォーマット（以下、DEXファイル）の実行可能ファイルにおける一つの特異性としては、ファイル内のコードの一部であり、実行ロジックを損失することなしに変更することができる。モバイル・アプリケーションを実行する他の技術もまた、前述の特徴を有するアンドロイド・ランタイム環境であることに留意すべきである。それゆえ、コードの類似性（例えば、ラインパターン又はアプリケーションの振る舞いの解析）の検索における、古典的なマルウェア検出方法を使用する技術は、このような悪質なファイルに対してほとんど影響を及ぼさず、上記提示のアンチウィルス手法は、このような悪質なプログラム（ファイル）を明らかにすることができない。したがって、より効果的な方法が、ファイルの類似性を決定するために必要とされる。

それゆえ、悪質なプログラムを解析し識別する新しい原理は、モバイルプラットフォーム（特にAndroidモバイルプラットフォーム）に適応するのと同時に、多様性でプログラムコードを難読化している技術に対抗できることが必要とされている。

モバイルデバイスでの悪質なファイルを検出するためのシステム、方法及びコンピュータプログラム製品が開示される。例示的な方法は、
ハードウェアプロセッサによって、少なくとも1つ又は複数のクラス、及び、1つ又は複数のクラスに含まれる1つ又は複数のメソッドを識別するために、ファイルを解析する工程と、
ハードウェアプロセッサによって、識別された各メソッド用のバイトコード配列を識別する工程と、
ハードウェアプロセッサによって、対応する操作コードを識別することにより、各メソッドの前記バイトコード配列から、各メソッドに含まれる命令を決定する工程と、
ハードウェアプロセッサによって、前記命令の中にある類似の機能性に基づいて、各メソッド用の決定された命令を、複数のグループに分割する工程と、
ハードウェアプロセッサによって、命令を複数のグループに分割した結果に基づいて、各メソッド用のベクトルを形成する工程と、
ハードウェアプロセッサによって、比較されたベクトル間での類似度を決定するために、前記解析ファイルのメソッド用の形成されたベクトルを、データベースに格納されている既知の悪質なファイルの複数のベクトルと比較する工程と、
ハードウェアプロセッサによって、比較されたベクトル間の類似度に基づいて、解析ファイルが悪質又はクリーンであるかについて決定する工程を含む。

1つの例示的な態様では、ファイルを解析する工程は、ファイルを逆アセンブル及び逆コンパイルする工程を1又は複数含む。

1つの例示的な態様では、命令は、バイトコード配列の語義的な値に基づいてグループに分けられる。

1つの例示的な態様では、複数のグループは、論理的な意味を持たない命令、定数を操作する命令、フィールドを操作する命令、コール又は傍受に関連する命令のうち1つ又は複数のグループを含む。

1つの例示的な態様では、ベクトルを比較する工程は、n次元ユークリッド空間におけるそれらの関連する2つの点間の距離を比較する工程を含む。

1つの例示的な態様では、ベクトルを比較する工程は、
標準ライブラリのパッケージに属するクラス及びメソッドを比較から除外する工程と、
単一のメソッドを含まないクラスを比較から除外する工程と、
2つ又はそれより少ない命令を含むメソッドを比較から除外する工程と、
これらのファイルにおけるクラスとメソッドの総数（全体的な数）と、チェックされているファイルにおけるクラスとメソッドの総数との比較が、25％を超えて異なる場合、データベースに格納されているベクトルを持つファイルを比較からさらに除外する工程と、
比較されているファイルのクラス又はメソッドのサイズが25％を超えて異なる場合、前記比較されているファイルにおけるクラス又はメソッドを更なる比較から除外する工程と、
単一のクラスに含まれているだけのメソッドのベクトルを、前記比較から除外する工程と、
のうち、１つ又は複数を実行する工程を含む。

悪質なファイルを検出するための例示的なシステムでは、
ハードウェアプロセッサが、
少なくとも1つ又は複数のクラス及び、前記1つ又は複数のクラスに含まれる1つ又は複数のメソッドを識別するためにファイルを解析し、
識別された各メソッド用のバイトコード配列を識別し、
対応する操作コードを識別することにより、各メソッドの前記バイトコード配列から、各メソッドに含まれる命令を決定し、
前記命令の中の類似の機能性に基づいて、各メソッド用の前記決定された命令を、複数のグループに分割し、
前記命令を複数のグループに分割した結果に基づいて、各メソッド用のベクトルを形成し、
前記比較されたベクトル間の類似度を決定するために、前記解析ファイルのメソッド用の前記形成されたベクトルを、データベースに格納されている既知の悪質なファイルの複数のベクトルを比較し、
および、前記比較されたベクトルの間の類似度に基づいて、前記解析ファイルが悪質又はクリーンであるかについて決定する、
ように構成されている。

悪質なファイルを検出するために、コンピュータ実行可能命令を格納する例示的な非一過性コンピュータ可読媒体は、
少なくとも1つ又は複数のクラス、及び前記1つ又は複数のクラスに含まれる1つ又は複数のメソッドを識別するために、ファイルを解析する命令と、
識別された各メソッド用のバイトコード配列を識別する命令と、
対応する操作コードを識別することにより、各メソッドの前記バイトコード配列から、各メソッドに含まれる命令を決定する命令と、
前記命令の中の類似の機能性に基づいて、各メソッド用の前記決定された命令を、複数のグループに分割する命令と、
前記命令を複数のグループに分割した結果に基づいて、各メソッド用のベクトルを形成する命令と、
前記比較されたベクトルの間の類似度を決定するために、前記解析ファイルのメソッド用の形成されたベクトルを、データベースに格納された既知の悪質なファイルの複数のベクトルと比較する命令と、
前記比較されたベクトル間の類似度に基づいて、前記解析ファイルが悪質又はクリーンであるかについて決定する命令と、を含む。

例示的態様における上記の簡単な概要は、本開示の基本的な理解を提供するのに役立つ。この概要は、すべての企図される態様における広範な概観ではなく、すべての態様の主要又は重要な要素を特定することも、本開示の全て又は任意の範囲の態様を線引きすることも意図されていない。その唯一の目的は、以下の開示のより詳細な説明の前置きとして簡略化された形式で、1つ又は複数の態様を提示することである。前述の達成のために、本開示の1つまたは複数の態様は、特許請求の範囲に記載され、特に指摘された特徴を含む。

添付図面は、本明細書に組み込まれ、その一部を構成しており、本開示の1つ又は複数の実施の態様を示しており、詳細な説明と共に、その原則と実装を説明するのに役立つ。
図1Aは、DEXフォーマットの実行可能ファイルの典型的な構成図を示す。 図1Bは、DEXフォーマットの実行可能ファイルの例を示す。 図2は、モバイルデバイスでの悪質なファイルを検出する例示的なシステムを示す。 図3は、モバイルデバイスでのDEXフォーマットの実行可能ファイルの中にある悪質なファイルを検出するための例示的なアルゴリズムを示す。 図4は、ファイルの類似度の判断の精度を高めるための例示的なアルゴリズムを示す。 図5は、ベクトルを生成するために使用される“onReceive”手法の例示的なコードを含む表を示す。 図6は、開示されたシステム及び方法を実装することができる汎用コンピュータシステムの一例を示す。

例示的態様は、モバイルデバイスでの悪質なファイルを検出するためのシステム、方法、及びコンピュータプログラム製品における説明で本明細書に記載されている。当業者は、以下の説明は単なる例示であり、いかなる方法においても限定されることを意図するものではないことを理解するであろう。他の態様は、本開示の利益を有する当業者に対して容易に示される。添付の図面に示されるように、参照は、今、例示的態様の実装に対して詳細に説明される。同じ参照指標が、同一または同様の項目を参照するために、図面全体と以下の説明を通じて、可能な限り使用される。

モバイルデバイスでの悪質なファイルを検出するためのシステム、方法、及びコンピュータプログラム製品の例示的な態様は、Android OSにおいて、本明細書に説明される。しかし、当業者は、これらの態様が他のモバイルオペレーティングシステムとプラットフォームに適合できることを、容易に理解するであろう。Android OSで実行されるアプリケーションの特殊性が、まず始めに検討される。Android OS用のアプリケーションを作成する場合、ファイルは、Android Packフォーマット（以下、アークファイルarc file）で構成され、それは、原則的にアーカイブである。アーカイブは、一般的に、以下のファイル、"META-INF"ディレクトリ、"res"ディレクトリ、ファイル"AndroidManifest.xml"、ファイル"classes.dex"およびファイル"resources.arsc"が含まれている。

META-INFディレクトリは、順番に、ファイルCERT.RSA（アプリケーションの証明書）、ファイルCERT.SF（リソースファイル（画像、音等）のチェックサムを含む）、及び、ファイルMANIFEST.MF（apkファイル自体を記述したサービス情報を含む）を含み。つまり、このフォルダは、アプリケーションの署名ファイルを含むものであり、それは、開発者の会社によって上記アプリケーションを証明するものである。

"res"フォルダは、様々なリソースファイルを含み、例えば、それは、インターフェース及び画像を表示すること及びアプリケーションの曲を再生することを可能にしている。

ファイル"AndroidManifest.xml"は、いわゆる"apkアプリケーションのパスポート"である。このファイルには、アプリケーションにおける一般的な情報が含まれ、それは、ネットワーク又は連絡先へのアクセスに関する情報など、アプリケーションの動作のために必要なサービス情報を含むものである。

ファイル"resources.arsc"は、リソースの表である。ファイルは、XMLハイパーテキストの形式（拡張マークアップ言語）ですべてのリソースの記述を含むものである。

ファイル"classes.dex"は、Dalvik実行可能フォーマット（以下、DEX）の実行可能ファイルであり、仮想マシンのDalvik（以下、VMD）で動作するために必要なバイトコードおよびサービスの情報が含まれている。VMDがAndroid OSでのアプリケーションの実行の主要な方法であることに留意すべきである。DEXフォーマットの属性は、プログラムの構成要素（例えば、クラス、メソッド、フィールド、例外ハンドラなど）の完全な情報を得ることができるのと同様に、それらの振る舞いを決定するバイトコードと共に、これらの要素と関連付けされている

図1Aは、ファイルの構成要素の一部であるDEXファイル100の構造図を示す。DEXフォーマット100のファイルは、クラス110а...110nで構成されている。オブジェクト指向プログラミングでは、クラスは、データにおける様々な抽象型を意味し、それは、その構築メソッドによって特徴付けられる。順に、データにおける抽象的な型は、対応する型の要素で動作するために、特定の一連のメソッド120а...120nを提供するデータの型を意味し、また、特別な他のメソッドの助けを借りて、この型の要素を確立（形成）する能力を意味する。DEXフォーマット100の各ファイル用のクラス110及びメソッド120の数は、対応するアプリケーションの目標及びタスクに応じて変化する。各メソッドは、VMD命令を含む。VMDの命令のフォーマットは、次の形式で提示することができる。

見て分かるように、命令は二つの部分に分割されており、第一の部分は、命令のオペレーションコード（「OPCODE」）を含む。第二の部分は、命令の引数を含み、（レジスタの値など）命令で使用されているレジスタ及び他のパラメータを定義する。DEXフォーマットである実行可能ファイルにおけるソースコードの例を図1Bに示す。パッケージ"com.soft.android.appinstaller"は示され、そのソースコードは、DEXフォーマットのファイルを構築するために使用され、そのクラスは、tree構造の形（ActivityTexts、FinishActivity等）で提示される。さらに、このクラス"messageSender"の命令は、図1Bの右側に示される。各メソッドは、目的を実行するため、特定の数のコマンドを原則的に含み、一連の入力引数を持っていることに留意すべきである。したがって、DEXフォーマットであるファイルでのクラスにおけるメソッド毎に、1つが対応するバイトコード配列（例えば、命令のセット）を定義することができる。

一実施態様では、プログラムの構造要素（メソッド及びクラス等）の機能の比較に基づいて、DEXフォーマットのファイルを比較する、悪質なファイルを検出するためのメソッドは、前記ファイルに含まれる。このようなアプローチは、DEXフォーマットのファイル用のファイルを、バイナリで、行ごと（ライン・バイ・ライン）に比較する既知のメソッドの欠点を克服する。欠点の1つは、単一のバイトコードの順序を前提とするバイナリ比較は、バイトコード配列の順序を変更することによって回避されることである。他の欠点は、同じサイズのラインが暗号化されたときに、行ごと（ライン・バイ・ライン）の比較が機能しないということである。

図2は、Android OSベースのデバイス（以後、簡潔には、検出システム）等、モバイルデバイスで悪質なファイルを検出する例示的なシステムを示す。示されるように、検出システム200は、悪質なファイルを検出するために、モバイルデバイス20にインストールされることができる。図6に示されるように、モバイルデバイスは、コンピュータシステムの特定の事例であるが、それは、Android OSを用いる、モバイル電話、スマートフォン、パーソナルコミュニケーション、又はタブレットコンピュータを含むことができる、ことに留意されたい。
従って、アンチウィルスの保護を必要とするモバイルデバイスでの実行ファイルは、一般的に、DEXフォーマット100の実行ファイル（ファイル1、ファイル2、ファイル3及び、ファイルN、ファイル100の各々）である。従って、各ファイル100の実行前に、検出システム200は、ファイル100のアンチウィルスチェックを実行することができる。

1つの例示的な態様で、検出システム200は、少なくとも解析モジュール210、ベクトル生成モジュール220、比較モジュール230、及びベクトルデータベース240を含む。
同様に、1つの例示的な態様で、検出システム220は最適化モジュール250を含む。
さらに、検出モジュール200は、アンチウィルスサーバ280等のリモートサーバと接続することができる。
例えば、サーバ280との接続は、インターネット270を介してなされるだろう。アンチウィルスサーバ280は、解析モジュール210、ベクトル生成手段220、及び比較モジュール230の機能を提供する1つの例示的な態様を含む。この場合、解析モジュール210、ベクトル生成モジュール220、及び、比較モジュール230は、それらのタスクの一部又は全ての方向を、アンチウィルスサーバ280における対応するモジュールに変えることができる。
その後、解析モジュール210、ベクトル生成モジュール220、及び比較モジュール230は、検出システム220が動作するために、必要な情報を送受信しつつ、監視手段として、機能するだろう。
さらに他の実施態様で、前述したモジュール210、220、230、240、及び250が、リモートサーバ280に配置されることができ、そしてその後、通信モジュール290は、相互で作用する前記モジュールとモバイルデバイス20のタスクを実行することができる。
例えば、通信モジュール290は、実行されるアンチウィルスチェックを持つ必要があるファイル、又は、アンチウィルスチェック（ファイルのハッシュ合計等）を実行するのに充分なファイルでのデータを送信するだろう。
それゆえ、1つの例示的な態様での検出システム200は、分散型の検出システムであり得る。

したがって、解析モジュール210は、ファイルコンテンツ（特に、識別されるクラスに含まれる、クラス及びメソッド）についての情報を識別するために、チェックされているファイルの解析を実行する。1つの例示的な態様で、解析モジュール210は、ファイルの実行コードをプログラムのソースコードに変換するために、逆アセンブリすることによって、そのファイルを切り離すように構成される。
この後、ファイルの内容の構成、すなわち、メソッド及びクラスに関する情報は、決定される。
ファイルの逆アセンブリのために、モジュール210は、逆アセンブリ機能であってもよく、又はそれを含んでいてもよい。他の例示的な態様では、切り離されたファイルは、ファイルを逆コンパイルするよって得られることができる。
ファイルを逆コンパイラするために、解析モジュール210は、ファイルの逆コンパイル機能であってもよく、又はそれを含んでいてもよく、逆コンパイラ“ApkTool”等、DEXフォーマットのファイルを切り離しておくように構成されている。

次に、各クラスのメソッドを識別するために、解析モジュール210は、対応するバイトコード配列（一連の命令セット）を決定することができる。基本的には、バイトコード配列は、仮想マシンのコード内の特定のメソッドの表現である。バイトコードの配列を決定すると、解析モジュール210は、与えられた配列を、複数の命令（コマンド）にばらばらにすることができる。このように、“機能マップ”は、解析されているファイルの各クラスの各メソッドのために形成されている。解析モジュール210が、配列を複数の命令にばらばらにし、バイトコードの決定をする場合、モジュール210は、DEXフォーマットのアプリケーション（ファイル）に対して、命令長の逆アセンブルの機能を基本的に実行している。

次に、解析モジュール210は、特定された情報（すなわち、メソッド及び、対応するバイトコードを有するそれらの対応する命令）をベクトル生成モジュール220へ転送することができる。例えば、クラスからの少なくとも1つのメソッドも存在しないことを見つけた場合に、クラスは重要でないと考えることができることに留意されたい。さらに他の例示的な態様では、メソッドが2つより少ない命令（コマンド）を含む場合、そのメソッドも重要でないと考えることができる。クラス又はメソッドが重要でないと判断された場合、1つの例示的な態様によれば、さらなる解析から除外されてもよいことを意味することに留意すべきである。この最適化により、さらなる解析の速度を向上させ、偽陽性検出のレベルを低減することができる。

1つの例示的な態様では、ベクトル生成モジュール220は、解析モジュール210から受けとった情報に基づいて、すなわち、各メソッドのバイトコードの解析の基礎に基づいて、各メソッド（チェックされているファイルのメソッドを含む）に対するベクトルを形成するように構成されている。ベクトルの生成の原理は、“onReceive”メソッド用のベクトルにおける、例示的なフォーメーションとして用いられ、次に示されるだろう。“onReceive”メソッドのコードは、ラインで分割され、図5での表1に示されている。表1から分かるように、各ラインは、その引数及びレジスタとの対応するオフセットによってVMDための命令コードを構成している。メソッド用のベクトルを形成する場合、ベクトル生成モジュール220は、命令の最初のバイトのみを選択し、それは、命令によって実行されるアクションを決定する。言い換えれば、我々は命令の“OPCODE（オペコード）”を選択し、それは、一般的に、最初のコードバイトによって特徴付けられる。表1によれば、最初のバイトはマシンコードの最初の2桁（すなわち、オフセット0000における最初の行の6E、オフセット0006における二行目の0Aなど）となる。それゆえ、バイト6E、0A、2B、54、71、0E、54、71、0A、D8、71、54、71、0C、71、0C、6E、0C、1F、52、54、71、0A、33、54、71および28が選択されるだろう。

次に、ベクトル生成モジュール220は、ある機能グループに属する命令の数をカウントする。
ある命令における、対応する機能グループ（以下、グループ）のどれに属するのであるかの決定は、例えば、対応関係のテーブルを用いて行うことができ、その例は、表2である。表2によれば、あるグループへの命令の所属は、命令のオペコードによって決定することができる。
表 2

例えば、”onReceive"メソッドに対して、制御転送グループ（換言すれば、”invoke（起動）”コールのグループ）又はグループ1は、6E及び71のような命令のオペコードを含む。それゆえ、ベクトル生成モジュール220は、例えば、それらの機能の類似性に基づいて（命令のオペコードの語義的な値に応じて）、nグループに、全ての命令セットをばらばらにする。後に分散されるであろう命令（コマンド）が自動的に作成され、又はユーザのヘルプに先立って、指定されることができることに留意すべきである。
各グループの例は、論理的な意味を持たない命令群（例えば、レジスタ間のデータを転送するための命令等）、定数を操作するための命令群、フィールドを操作するための命令群、コールのための命令群、転送の傍受及び/又は制御する命令群でありえる。

すべての命令をグループに分割した後、例えばベクトル生成モジュール220は、n次元ユークリッド空間内のベクトル（点）の形式で、各メソッドを提示することができる。

ここで、Mは、メソッドであり、F(M)は、メソッドの機能マップである。
mは、メソッドに対応するn次元空間内の点であり、かつ
は、指定されたグループに応じて、その語義的な値によってオペコードを分割したものである。

すなわち、ベクトルを形成する際に、グループでのコマンドの数により、対応する軸に沿ってベクトルの座標を決定する。解析中のファイルにおける、すべての決定されたクラスのメソッド用に形成されたベクトルは、ベクトル生成モジュール220によって比較モジュール230へ送信される。

1つの例示的な態様では、ベクトル生成モジュール220は、すぐにベクトルを形成するわけではなく、その前に、標準ライブラリ・パッケージ（例えば、それらはソフトウェア開発キットの一部である）に関連するクラス及びメソッドを特定し、さらなるチェックから除外することができる。例えば、標準ライブラリパッケージに、メソッド及び/又はクラスのバイトコード（オペコード）が所属しているという決定に基づいて行われる。

1つの例示的な態様では、比較モジュール230は、ベクトルデータベース240に格納されたファイルのメソッドにおけるベクトルと共に、チェックされているファイルのメソッドにおける形成されたベクトルを用いて、ファイルの比較を行う。ファイルのメソッドにおけるベクトルで生じる表現により、比較モジュール230は、n次元ユークリッド空間におけるそれらの関連する2つの点間の距離として、比較されるファイルの最も近い2つのメソッドの違いの度合いの数（表現）として生成できる。換言すれば、各点について、ある１つが他のファイルの他のメソッドの最も近い点を見つけ、その点の間の距離が決定される。特定の態様では、比較するために、モジュール230は、レーベンシュタイン・アルゴリズム又は任意の類似したアルゴリズムを使用することができる。

従って、例えば、メソッドのpとqのための距離は、以下の式で計算できる。
ここで、diffは、関連する2つの点間の距離である。

それゆえ、一定の距離“diff”（相違度）が決定され、それは、その後、形成されるベクトルの長さ（コマンドの総数）に正規化される。比較されているメソッドは、それらの正規化された相違度ほど類似していないと考えられている。相違度は、相違度0から1の間にある。

次に、比較モジュール230は、ベクトルデータベース240に格納されているファイルと、チェックされているDEXフォーマット100のファイルの類似性について判断を示す。この後、比較モジュール230は、最も類似であると識別されたファイルによって、チェックされているDEXフォーマット100のファイルが悪意を持っているかどうかを決定する。最も類似のファイルが悪質なファイルである場合には、チェックされているファイルは、悪意があるとみなされる。そうでなく、最も類似のファイルが、クリーンなファイル（悪意のない）である場合、チェックされているファイルもクリーンであるとみなされる。１つのファイル又は他の悪意についての情報は、さらに、ベクトルデータベース240に格納される。

そうであっても、ファイルの類似度を決定する際に、まず、それらのメソッドの比較、それから、それらのクラスの比較を行い、最終的な決定を下すということに留意すべきである。それゆえ、特定の態様において、メソッドが、互いに50％未満の類似である場合、そのメソッドは全く似ていないとみなされる。このような場合において、メソッドの類似性は、それらに含まれる命令（オペコード）の合計によって決定されてもよい。従って、オペコードがより多く識別されるほど、メソッドの類似性も増加する。クラスが10％を超えて異なる場合にも、クラスは異なることになる。与えられた場合には、クラスの類似性は、その中に含まれるメソッドの合計（数）によって決定することができる。

この正規化された相違度は、以下の式によって計算することができる。

さらに、他の例示的な態様でのファイルの類似度の決定の精度を高めるために、最適化モジュール250は、それら（ベクトルデータベース240に格納されているメソッドのベクトル）と、チェックされているファイルのメソッドのベクトルとの比較に先立って、ベクトルデータベース240に格納されているメソッドのベクトルの最適化を行うことができ、及び/又は、2つのファイルを比較した瞬間に直接最適化を行うことができる。

1つの例示的な態様では、最適化モジュール250は、お互いに、すべてのメソッド（より正確には、それらのベクトル）ではなく、最も近いもののみで比較を行うことで、最適化を実行するように構成されている。このため、このメソッドは、昇順にソートされてもよい。ソートは、各メソッドの命令数（合計）に応じて行うことができる。

1つの例示的な態様では、最適化モジュール250は、例えば、類似クラス内でのみメソッドを比較して最適化を行うように構成されている。したがって、メソッドを比較する前に、モジュール250は、同様に、これらクラスを比較する。例えば、そのクラスが、それらに割り当てられた類似性の係数を満たす場合、対応するクラスのメソッドを比較する。これらクラスの類似度の係数は、例えば、各クラスに含まれるメソッドの数（合計）を比較することにより、計算されることができる。さらに、選択されたそのクラスは互いに比較され、そのクラス内での選択されたメソッドは、同様に、互いに比較されるべきであり、その選択は、対応するメソッドとクラスのサイズ（合計）との比較に基づくことができる。前述のように、そのサイズは、クラスに対するメソッドの数を加算すること、及び、メソッドに対する命令の数を加算することによって決定される。したがって、例えば、クラス又はメソッドを比較する時に、サイズが25％を超えて異なる場合、さらなる解析は行なわれないだろう。そうでなく、そのサイズが25％未満だけ異っている場合には、それらは比較されるだろう。

1つの例示的な態様では、比較モジュール230は、また、完全な比較の前にファイルの予備的な比較を行うことができる。この場合、各ファイルのクラス及びメソッドの総計は比較されることができる。ベクトルデータベース240からのファイルが、チェックされている現在のファイルと、どの方向にも25％を超えて異なっていない場合、ファイルのさらなる比較が行われる。そうでない場合、比較モジュール230は、ファイルが互いに異なるという判断を示す。

さらに他の例示的態様では、最適化モジュール250は、比較されるベクトル（点）の数を制限することによって、最適化を行うように構成されている。例えば、制限は、n次元ユークリッド空間内の特定の範囲によって確立することができ、それによって、たった1つのベクトル（点）がこの範囲内に収まるように、比較される。特定の態様において、その範囲は、全ての点の座標との合計に基づいて決定される。

なお、上記の予備的な最適化により、ファイルの比較の速度が向上され、結果として、ファイル100のチェック速度及び、それらの間で悪質なファイルを検出する速度が向上することになる点に留意すべきある。

図3は、モバイルデバイスでの悪質なファイルを検出する方法の一例を示す。一般的に、モバイルデバイス20での実行可能ファイルをアンチウィルスのチェックを実行している間に、ファイルは既知の悪質なファイルと比較される。これを行なうために、工程310で、解析モジュール210は、解析ファイルを分割する。逆コンパイル時に、工程320で、解析モジュール210は、ファイルの構造、特に、識別されたクラスに含まれるクラス及びメソッドのリストについての情報を識別する。工程330において、解析モジュール210は、識別された各メソッドの命令（コマンド）のリストを形成する。このため、対応するバイトコード配列（コマンドのセット）は、識別された各メソッドに対して決定される。バイトコード配列は、マシンコードでのあるメソッドにおける表現である。各メソッドに対するバイトコードの配列を選択すると、前記配列は、それ自身のバイトコードを有する個々の命令（コマンド）に分割される。したがって、機能マップは、解析されているファイルの各クラスの各メソッドのために形成され、対応するバイトコードを有する命令のリストを含むものである。

工程340で、ベクトル生成モジュール220は、命令のリストを少なくとも二つのグループに分割する。グループの型とその数を決定するための属性は、事前に指定され、又は自動的に指示されることができることに留意されたい。それゆえ、例えば、グループは、（それらの機能と類似している）オペコードの語義的な値に応じて作成されることができる。このようなグループの例としては、以下のものがある。
全く論理的な意味を持たない命令（レジスタ間でデータを転送する命令等）を記述したグループ、定数を操作するための命令を記述したグループ、フィールドを操作するためのグループ、コールのグループ、及び/又は、転送のグループ。
グループへの分割の原理は、命令のオペコードに付随する第一のバイトが抽出される時に、各命令に対してのバイトコード解析の実行に基づいている。分割の原理の一例として、図2の説明が提示される。

工程350で、グループへばらばらになった後、ベクトル生成モジュール220は、各メソッドのベクトルを形成する。それゆえ、ベクトルが形成された際に、各グループでのコマンドの数は、対応する軸に沿ったベクトルの座標を決定する。したがって、各メソッドは、n次元ユークリッド空間内のベクトル（点）の形で表されており、空間の次元は、グループの数に等しい。

工程360で、比較モジュール230は、ベクトルデータベース記憶手段240に格納されたファイルのベクトルを用いてファイルをチェックするため、形成されたベクトルによってファイルを比較する。比較の際に、相違度は、n次元ユークリッド空間におけるそれらの関連する2つの点間の距離と比較されているファイルの最も近い2つのメソッドの間で計算される。換言すれば、各点が、他のファイルにおける他のメソッドの最も近い点が見つけられ、点間の距離が決定される。距離の計算の一例として、図2に説明が提示される。したがって、距離が決定され、その後、形成されたベクトルの長さ（コマンドの総数）に正規化される。正規化された相違度の計算例は、図2に説明が提示される。比較されているメソッドは、それら正規化された相違度よりも少なくなればなるほど、類似度は増すと考えられている。

次に、工程370で、ファイルがチェックされているDEXフォーマット100のファイルの類似性における判断は明白であり、その（ファイルの）ベクトルは、データベース240に格納されている。この後、図2の説明で示されるように、識別された最も類似したファイルによって、チェックされているファイル100が悪質であるかどうかについて決定される。ファイルの悪質さ（又はそうでなく）における判断を顕著にすることができてから、類似の係数が、モバイルデバイス20で必要とされるセキュリティのレベルに応じて、決定（又は指定）されることに留意すべきである。

そうであっても、一連のファイルの類似度を決定は、以下のようにみることができる。まず、メソッドの比較がなされ、その後、クラスの比較、それから、類似性に関する最終決定が行われる。メソッドの比較は、各メソッドに含まれる命令の合計を計算することによって行うことができ、そして、クラスの比較は、各クラスに含まれるメソッドの合計を計算することに基づいて行われてもよい。特定の態様においては、メソッドが、互いに50％未満の類似度である場合、そのメソッドは類似ではないとみなされる。クラスが10％を超えて異なる場合、クラスは異なることになる。

図4は、ファイルの類似度を決定する精度を増加させるための例示的なアルゴリズムを示す。ファイルの類似度の決定の精度を高めるために、最適化モジュール250は、チェックされているファイルにおけるメソッドのベクトルの比較に先立って、又は、2つのファイルを比較する瞬間に、ベクトルデータベース240に格納されているメソッドベクトルのデータベースの最適化を実行することができる。

このように、工程410で、比較されているファイルのためのベクトルを形成する直前に、最適化モジュール250は、クラス及びメソッドのさらなるチェックを識別でき、それから除外することができる。それ（クラス及びメソッド）は、標準ライブラリ・パッケージ（例えば、ソフトウェア開発きっとの一部）に属する。さらに、少なくとも1つの重要でないメソッドは、任意の与えられたクラスで見つけられ、そのクラスは、重要でないと考えることができる。同様に、メソッドが2つ未満の命令（コマンド）を含む場合、そのメソッドは重要でないと考えることができる。

次に、ファイルの比較の際に、最適化は、比較されているファイルに対して実行され、それによって、その比較は、最も類似したファイルとそれらのメソッドに対して行われるのみである。したがって、工程430で、ファイルは、チェックされているファイルに最も類似しているものが見つけられる。このため、最適化モジュール250は、各ファイルのクラス及びメソッドの総計を比較する。ベクトルデータベース240からのファイルが、現在チェックされているファイルと、いずれかの方向で、25％を越えて異なっていない場合、さらなる比較が、そのファイルでなされるだろう。そうでなければ、そのファイルは、チェックされているファイルとは異なっていると見つけられるだろう。

そして、工程450で、最適化モジュール250は、チェックされているファイルとのその後の比較のために、工程430で見つけられたファイルのクラス及びメソッドのための最適化を行うことができる。最適化は、ファイルで比較されることになるクラス及びメソッドの決定を含むことができる。したがって、比較されたクラスとそのクラス内でのメソッドは、互いに比較するのと同様に、それらのサイズを比較することによって、選択される。例えば、サイズは、クラスに対するメソッドを追加し、メソッドに対する命令を追加することによって決定することができる。それゆえ、クラス又はメソッドを比較するときにサイズが25％を超えて異なる場合、それらのさらなる解析は成されない。そうでなく、サイズが25％未満だけ異なる場合、それらは比較される。

また、工程470で、比較されているベクトルの数は、ファイルの（対応するクラスでのメソッドの）工程450で見つけられたベクトルと直接比較することで、制限される。例えば、空間内の特定の範囲によって、制限を確立することができ、それによって、ベクトル（点）のみが、この範囲内に落とし込まれるように、比較されるだろう。この後、ファイルにおいける最終的な比較が、工程490で成される。

図6は、汎用コンピュータシステム（それはパーソナルコンピュータ又はサーバであってもよい）の一例を示し、そこで、開示されたシステム及びメソッドが、例示的態様に従って、実装されることができる。

示されるように、コンピュータシステムは、中央処理ユニット21、システムメモリ22及びシステムバス23を含み、システムバスは、様々なシステムコンポーネント（中央処理ユニット21に付随するメモリを含む）に接続している。システムバス23は、先行文献で知られている任意のバス構造のように実現され、順にバスメモリ又はバスメモリコントローラ、周辺バス、及びローカルバスを含み、それは、任意の他のバスアーキテクチャと相互作用することができる。システムメモリは、読み出し専用メモリ（ROM）24およびランダムアクセスメモリ（RAM）25を含む。基本入出力システム（BOIS）26は、パーソナルコンピュータ20の要素間で情報の転送を保証する基本的な手順を含み、ROM24を使用してオペレーティングシステムをロードする時にも同様である。

パーソナルコンピュータ20は、順に、データの読み書き用ハードディスク27、リムーバブル磁気ディスク29への読み書き用磁気ディスクドライブ28、及び、リムーバブル光ディスク31（CD-ROM、DVD-ROM又は他の光情報媒体等）への読み書き用光ドライブ30を含む。ハードディスク27、磁気ディスクドライブ28、及び光ドライブ30は、それぞれ、ハードディスクインターフェース32、磁気ディスクインタフェース33及び光ドライブインターフェース34を介してシステムバス23に接続されている。ドライブ及び対応するコンピュータ情報媒体は、パーソナルコンピュータ20のコンピュータ命令、データ構造、プログラムモジュール、およびその他のデータにおける記憶装置に対して電力独立型モジュールである。

本開示は、ハードディスク27、リムーバブル磁気ディスク29およびリムーバブル光ディスク31を使用するシステムの実装を提供するが、コンピュータによって読み取り可能な形式でデータを格納することができる他の種類のコンピュータ情報媒体56（ソリッドステートドライブ、フラッシュメモリカード、デジタルディスク、ランダムアクセスメモリ（RAM）等）を使用することも可能であることが理解されるべきであり、それらは、コントローラ55を介してシステムバス23に接続される。

コンピュータ20は、ファイルシステム36を有し、そこには記録されたオペレーティングシステム35が保持され、および、追加プログラムアプリケーション37、他のプログラムモジュール38およびプログラムデータ39、もまた同様である。
ユーザは、入力デバイス（キーボード40、マウス42）で、パーソナルコンピュータ20に、コマンドと情報を入力することができる。他の入力デバイス（図示せず）として、マイクロホン、ジョイスティック、ゲームコントローラ、スキャナ等を用いることができる。そのような入力デバイスは、通常、シリアルポート46を介してコンピュータシステム20に接続され、それは、順番に、システムバスに接続される。それらは、他の方法（例えば、パラレルポート、ゲームポート、又はユニバーサルシリアルバス（USB））を用いて接続できる。モニター47又は他の種類の表示デバイスもまた、ビデオアダプタ48などのインターフェースを介してシステムバス23に接続される。モニター47に加えて、パーソナルコンピュータは、ラウドスピーカー、プリンター等の他の周辺出力デバイス（図示せず）を搭載することができる。

パーソナルコンピュータ20は、1つ又は複数のリモートコンピュータ49を用いて、ネットワーク環境で作業することができる。図6に示すように、リモートコンピュータ（複数可）49も、前述の要素の大部分又は全てを有するパーソナルコンピュータ又はサーバであり、その要素は、パーソナルコンピュータ20の本質を示している。ルータ、ネットワーク局、ピアデバイスまたは他のネットワークノード等、他のデバイスも、コンピュータネットワークに存在できる。

ネットワーク接続は、有線および/または無線ネットワーク等のローカルエリアコンピュータネットワーク（LAN）50、およびワイドエリアコンピュータネットワーク（WAN）を形成することができる。このようなネットワークは、企業コンピュータネットワークと社内ネットワークで使用されており、これらは一般的にインターネットへのアクセス権を有している。LANまたはWANネットワークでは、パーソナルコンピュータ20は、ネットワークで使用しているネットワークアダプタまたはネットワークインタフェース51を介してローカルエリアネットワーク50に接続される。ネットワークが用いられる場合、パーソナルコンピュータ20は、インターネットのようなワイドエリアコンピュータネットワークとの通信を提供するため、モデム54または他のモジュールを使用する。モデム54は、内部または外部デバイスであり、シリアルポート46によってシステムバス23に接続される。ネットワーク接続は、単なる例であり、ネットワークの正確な構成を示す必要はないことに留意すべきである。すなわち、現実には、技術的な通信モジュールによる他のコンピュータの接続を確立する他の方法がある。

様々な態様において、本明細書で説明するシステム及び方法は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実装することができる。ソフトウェアで実装する場合、その方法は、非一時的なコンピュータ可読媒体上の1つまたは複数の命令またはコードとして格納されることができる。コンピュータ可読媒体は、データ記憶を含む。コンピュータ可読媒体を以下に例示するが、限定するものではない。コンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、フラッシュメモリ、又は、他の種類の電気的、磁気的、または光記憶媒体、又は他の任意の媒体、を備えることができ、命令またはデータ構造の形で所望のプログラムコードを搬送又は格納するために用いられ、汎用コンピュータのプロセッサによってアクセスすることができる。

様々な態様では、システムおよび方法は、モジュールの観点から、本開示で説明される。本明細書で使用される用語「モジュール」とは、現実世界のデバイス、コンポーネント、または、ハードウェアを用いて実装されたコンポーネントの配置を言及しており、例えば、または、ハードウェアとソフトウェアの組み合わせとして、特定用途向け集積回路（ASIC）またはフィールド・プログラマブル・ゲート・アレイ（FPGA）などによって実装され、モジュールの機能を実装するマイクロプロセッサシステムと命令セットなどによって、（実行される間に）マイクロプロセッサシステムを専用のデバイスに変換される。モジュールも、2つの組合せとして実装されることができ、ハードウェアだけによって容易とされる特定の機能、および、ハードウェアとソフトウェアの組み合わせによって容易とされる他の機能と、これらの組み合わせとして実現することができる。特定の実施態様では、少なくとも一部、およびいくつかのケースでは、モジュールのすべては、（例えば、図3上部に詳細に説明したもののように）汎用コンピュータのプロセッサ上で実行することができる。したがって、各モジュールは、適切な様々な構成で実現することができ、そして本明細書中に任意の例示的な実施形態に限定されるものではない。

明瞭にするために、態様のルーチン機能のすべてが、本明細書に開示されているわけではない。本開示における任意の実際の実装における開発で、多数の実装固有の判断が、開発者の特定の目標を達成するためになされなければならないことが理解されるであろう。さらに、これらの具体的な目標は、異なる実装及び異なる開発者に対して変化することが理解されるであろう。そのような開発努力は複雑で時間がかかるかもしれないが、それでも本開示の利益を有する当業者にとっては、エンジニアリングの日常の仕事であると理解されるであろう。

さらに、本明細書で使用される用語又は表現は、説明のためであり、制限するものではなく、つまり、関連技術の熟練の知識と組み合わせて、本明細書の用語または表現は、ここに示される教示及び指針に照らして当業者によって解釈されるべきであることが理解されるべきである。明示的な記載がない限り、明細書または特許請求の範囲内で、任意の用語に対して、珍しいまたは特別な意味を帰することは意図されていない。

本明細書で開示された様々な態様は、例示のために本明細書に言及した既知のモジュールの、現在および将来の既知の均等物を包含する。さらに、態様および用途を示し、説明してきたが、本明細書に開示された発明の概念から逸脱することなく、上述したよりも多くの改変が可能であることが、この開示の利益を有する当業者には明らかであろう。

Claims (18)

1. 悪質なファイルを検出するための方法であって、前記方法は、
   ハードウェアプロセッサによって、オブジェクト指向プログラム言語にて書かれたコードを含むファイルを解析して、解析された前記ファイルの少なくとも1つ又は複数のクラス、及び、前記1つ又は複数のクラスに含まれる1つ又は複数のメソッドを識別する、ファイルを解析する工程と、
   前記ハードウェアプロセッサによって、解析された前記ファイルの、識別された前記1つ又は複数のクラスの数及び識別された前記1つ又は複数のメソッドの数を決定する工程と、
   前記ハードウェアプロセッサによって、前記識別された各メソッド用のバイトコード配列を識別する工程と、
   前記ハードウェアプロセッサによって、対応する操作コードを識別することにより、各メソッドの前記バイトコード配列から、各メソッドに含まれる命令を決定する工程と、
   前記ハードウェアプロセッサによって、前記命令の中にある類似の機能性に基づいて、各メソッド用の前記決定された命令を、複数のグループに分割する工程と、
   前記ハードウェアプロセッサによって、前記命令を前記複数のグループに分割した結果に基づいて、各メソッド用のベクトルを形成する工程と、
   解析された前記ファイルの、前記メソッドの数及び前記クラスの数のうちの少なくとも一方をデータベース内の既知の悪質なファイルと比較して、分析された前記ファイルの前記クラスの数及び前記メソッドの数よりも所定のパーセンテージ少ないクラスの数及びメソッドの数のうちの少なくとも一方を有する比較のための前記既知の悪質なファイルを識別する、比較工程と、
   前記ハードウェアプロセッサによって、比較されたベクトル間での類似度を決定するために、前記解析ファイルのメソッド用の形成されたベクトルを、識別された比較用の前記既知の悪質なファイルの複数のベクトルと比較する工程と、
   前記ハードウェアプロセッサによって、前記比較されたベクトル間の類似度に基づいて、前記解析ファイルが悪質又はクリーンであるかについて、決定する工程と、
   を含み、
   各メソッド用の前記ベクトルは、n次元ユークリッド空間内の点を含む、方法。
2. ファイルを解析する工程は、前記ファイルを逆アセンブリ及び逆コンパイルする工程を1つ又は複数含む、
   請求項1に記載の方法。
3. 前記命令は、前記バイトコード配列のセマンティック値に基づいて、グループに分けられる、
   請求項1に記載の方法。
4. 前記複数のグループは、
   論理的な意味を持たない命令、定数を操作する命令、フィールドを操作する命令、コール又は傍受に関連する命令、
   のうち、1つ又は複数のグループを含む、
   請求項1に記載の方法。
5. 前記ベクトルを比較する工程は、n次元ユークリッド空間におけるそれらの関連する2つの点間の距離を比較する工程を含む、
   請求項1に記載の方法。
6. 前記ベクトルを比較する工程は、
   標準ライブラリのパッケージに属する、クラス及びメソッドを前記比較から除外する工程、
   単一のメソッドを含まないクラスを前記比較から除外する工程、
   2つ又はそれより少ない命令を含むメソッドを前記比較から除外する工程、
   単一のクラスに含まれているだけのメソッドのベクトルを、前記比較から除外する工程、
   のうち、１つ又は複数を実行する工程を含む、
   請求項1に記載の方法。
7. 悪質なファイルを検出するためのシステムであって、
   ハードウェアプロセッサが、
   オブジェクト指向プログラム言語にて書かれたコードを含むファイルを解析して、解析された前記ファイルの少なくとも1つ又は複数のクラス、及び、前記1つ又は複数のクラスに含まれる1つ又は複数のメソッドを識別し、
   解析された前記ファイルの、識別された前記1つ又は複数のクラスの数及び識別された前記1つ又は複数のメソッドの数を決定し、
   識別された各メソッド用のバイトコード配列を識別し、
   対応する操作コードを識別することにより、各メソッドの前記バイトコード配列から、各メソッドに含まれる命令を決定し、
   前記命令の中の類似の機能性に基づいて、各メソッド用の前記決定された命令を、複数のグループに分割し、
   前記命令を複数のグループに分割した結果に基づいて、各メソッド用のベクトルを形成し、
   解析された前記ファイルの、前記メソッドの数及び前記クラスの数のうちの少なくとも一方をデータベース内の既知の悪質なファイルと比較して、分析された前記ファイルの前記クラスの数及び前記メソッドの数よりも所定のパーセンテージ少ないクラスの数及びメソッドの数のうちの少なくとも一方を有する比較のための前記既知の悪質なファイルを識別し、
   前記比較されたベクトル間の類似度を決定するために、前記解析ファイルのメソッド用の前記形成されたベクトルを、識別された比較用の前記既知の悪質なファイルの複数のベクトルを比較し、
   および、前記比較されたベクトルの間の類似度に基づいて、前記解析ファイルが悪質又はクリーンであるかについて決定する、
   ように構成され、
   各メソッド用の前記ベクトルは、n次元ユークリッド空間内の点を含む、システム。
8. 前記ファイルを解析することは、前記ファイルを逆アセンブリ及び逆コンパイルする工程を1つ又は複数含む、請求項7に記載のシステム。
9. 前記命令は、前記バイトコード配列のセマンティック値に基づいて、グループに分けられる、請求項7に記載のシステム。
10. 前記複数のグループは、
    論理的な意味を持たない命令、定数を操作する命令、フィールドを操作する命令、コール又は傍受に関連する命令、
    のうち、1つ又は複数のグループを含む、請求項7に記載のシステム。
11. 前記ベクトルを比較することは、n次元ユークリッド空間におけるそれらの関連する2つの点間の距離を比較することを含む、
    請求項7に記載のシステム。
12. 前記ベクトルの比較は、
    標準ライブラリのパッケージに属する、クラス及びメソッドを前記比較からの除外、
    単一のメソッドを含まないクラスを前記比較からの除外、
    2つ又はそれより少ない命令を含むメソッドを前記比較からの除外、
    単一のクラスに含まれているだけのメソッドのベクトルを、前記比較からの除外、
    のうち、1つ又は複数を実行することを含む、
    請求項7に記載のシステム。
13. 悪質なファイルを検出するため、コンピュータ実行可能命令を格納する一時的でないコンピュータ可読媒体であって、前記命令は、
    オブジェクト指向プログラム言語にて書かれたコードを含むファイルを解析して、解析された前記ファイルの少なくとも1つ又は複数のクラス、及び前記1つ又は複数のクラスに含まれる1つ又は複数のメソッドを識別するために、ファイルを解析する命令と、
    ハードウェアプロセッサによって、解析された前記ファイルの、識別された前記1つ又は複数のクラスの数及び識別された前記1つ又は複数のメソッドの数を決定する命令と、
    識別された各メソッド用のバイトコード配列を識別する命令と、
    対応する操作コードを識別することにより、各メソッドの前記バイトコード配列から、各メソッドに含まれる命令を決定する命令と、
    前記命令の中の類似の機能性に基づいて、各メソッド用の前記決定された命令を、複数のグループに分割する命令と、
    前記命令を複数のグループに分割した結果に基づいて、各メソッド用のベクトルを形成する命令と、
    解析された前記ファイルの、前記メソッドの数及び前記クラスの数のうちの少なくとも一方をデータベース内の既知の悪質なファイルと比較して、分析された前記ファイルの前記クラスの数及び前記メソッドの数よりも所定のパーセンテージ少ないクラスの数及びメソッドの数のうちの少なくとも一方を有する比較のための前記既知の悪質なファイルを識別する、比較命令と、
    前記比較されたベクトルの間の類似度を決定するために、前記解析ファイルのメソッド用の形成されたベクトルを、識別された比較用の前記既知の悪質なファイルの複数のベクトルと比較する命令と、
    前記比較されたベクトル間の類似度に基づいて、前記解析ファイルが悪質又はクリーンであるかについて決定する命令と、を含み、
    各メソッド用の前記ベクトルは、n次元ユークリッド空間内の点を含む、一時的でないコンピュータ可読媒体。
14. ファイルの解析は、前記ファイルを逆アセンブリ及び逆コンパイルする工程を1つ又は複数含む、請求項13に記載の一時的でないコンピュータ可読媒体。
15. 前記命令は、前記バイトコード配列のセマンティック値に基づいて、グループに分けられる、請求項13に記載の一時的でないコンピュータ可読媒体。
16. 前記複数のグループは、
    論理的な意味を持たない命令、定数を操作する命令、フィールドを操作する命令、コール又は傍受に関連する命令、
    のうち、1つ又は複数のグループを含む、
    請求項13に記載の一時的でないコンピュータ可読媒体。
17. 前記ベクトルの比較は、n次元ユークリッド空間におけるそれらの関連する2つの点間の距離の比較を含む、
    請求項13に記載の一時的でないコンピュータ可読媒体。
18. 前記ベクトルの比較は、
    標準ライブラリのパッケージに属する、クラス及びメソッドを前記比較からの除外、
    単一のメソッドを含まないクラスを前記比較からの除外、
    2つ又はそれより少ない命令を含むメソッドを前記比較からの除外、
    単一のクラスに含まれているだけのメソッドのベクトルを、前記比較の除外、
    のうち、１つ又は複数を実行することを含む、
    請求項13に記載の一時的でないコンピュータ可読媒体。