JP2017509962A - 構造化ファイルからの静的特徴抽出 - Google Patents

Abstract

実行環境によって要求されるデータをカプセル化する構造化ファイルを含むデータは、構造化ファイル内部でラップされる実行コードを管理するために、受信され、及びアクセスされる。その後に、コード及びデータ領域は、構造化ファイルにおいて繰り返し特定される。そのような特定は、少なくとも一つの特徴が構造化ファイルから抽出され得るように分析される。関連する装置、システム、技術及び製品も、記載する。

Description

本出願は、２０１４年１月３１日出願の米国特許出願第１４／１６９，８０８号の優先権を主張し、その内容は、参照の上、全体として本明細書に組み込まれている。

本明細書に説明される発明の要旨は、Ｐｏｒｔａｂｌｅ Ｅｘｅｃｕｔａｂｌｅ（ポータブル エグゼキュータブル）フォーマットファイルなどの構造化ファイルからの機械学習特徴を抽出することに関する。

ポータブル エグゼキュータブル フォーマットファイルなどの構造化ファイルは、ラップされる実行コードを管理するために、実行環境ローダに要求される情報をカプセル化する。ポータブル エグゼキュータブル（ＰＥ）フォーマットファイルは、ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムにより用いられる構造化ファイルの一種であり、実行ファイル、オブジェクトコード、ＤＬＬｓ、ＦＯＮフォントファイル及びその他のファイルのタイプを含む。構造化ファイルは、リソース（例えば、画像及び文字）並びに記述的及び規範的メタデータを含むさらなるデータを含み得、それ自体は、例えば、マルウェアの挿入などの悪意のある目的のためにしばしば用いられる。

一つの形態において、構造化ファイル内部でラップされる実行コードを管理するために、実行環境によって要求されるデータをカプセル化する構造化ファイルを含むデータは、受信され又はアクセスされる。その後に、コード及びデータ領域が、構造化ファイル内で繰り返し特定される。そのような特定は、少なくとも一つの特徴が構造化ファイルから抽出され得るように分析される。

構造化ファイルは、ポータブル エグゼキュータブル（ＰＥ）フォーマットファイル、Ｄｉｓｋ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ディスク オペレーティング システム）（ＤＯＳ）実行ファイル、Ｎｅｗ Ｅｘｅｃｕｔａｂｌｅ（ニュー エグゼキュータブル）（ＮＥ）ファイル、Ｌｉｎｅａｒ Ｅｘｅｃｕｔａｂｌｅ（リニア エグゼキュータブル）（ＬＥ）ファイル、Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋａｂｌｅ Ｆｏｒｍａｔ（エグゼキュータブル アンド リンカブル フォーマット）（ＥＬＦ）ファイル、ＪＡＶＡ（登録商標） Ａｒｃｈｉｖｅ（ジャバ アチーブ）（ＪＡＲ）ファイル、及びＳＨＯＣＫＷＡＶＥ／ＦＬＡＳＨ（ショックウェーブ／フラッシュ）（ＳＷＦ）ファイルを含むがそれらに限定されない、多様な形式が採用され得る。

実行環境は、例えば、オペレーティングシステム又はバーチャルマシンであればよい。

いくつかの変形例において、構造化ファイルが有効なシグネチャをカプセル化するかどうかを判別するために、構造化ファイル内部の少なくとも一つのヘッダを調べることによって、構造化ファイルが有効であることが判別され得る。

抽出された少なくとも一つの特徴は、１次の特徴であり得る。抽出された少なくとも一つの１次の特徴は、高次の特徴の中へ導出され得る。

さらに、ネガティブスペースは、構造化ファイル内で分析され得、少なくとも一つのさらなる特徴を抽出する。この点で、ネガティブスペースは、特定されたコード及びデータ領域と異なる。

抽出された少なくとも一つの特徴は、変換され得る。例としての変換は、抽出された少なくとも一つの特徴を無効化するステップ、抽出された少なくとも一つの特徴を切り詰めるステップ、又は少なくとも一つの特徴の少なくとも一部をエンコードするステップ、の一つ又はそれ以上を含み得る。

構造化ファイル内でコード及びデータ領域を特定することは、構造化ファイルを構文解析し及び逆アセンブリするステップを含み得る。構造化ファイル内のデータは、階層的に配置され、及び構造化ファイルは、第２のデータ構造体をカプセル化する第１のデータ構造体をカプセル化するトップレベルヘッダを含み得る。

構造化ファイル内のコード及びデータ領域を繰り返し特定するステップは、構造化ファイル内のコード及び／又はデータ領域のタイプを特定するステップを含み得る。

抽出された少なくとも一つの特徴は、いくつかの場合において、モデルによる消費／使用のために、機械学習モデルに提供され得る。少なくとも一つの特徴は、さらなる／中間の処理が、そのような特徴を用い、モデルに要求されないように、抽出され得る。

命令をストアする持続性のコンピュータプログラムプロダクト（すなわち、物理的に統合されたコンピュータプログラムプロダクト）も記載するのであり、その命令は、一つ又はそれ以上のコンピュータシステムの一つ又はそれ以上のデータプロセッサ上で実行される際に、少なくとも一つのデータプロセッサに本明細書のオペレーションを実行させる。同様に、一つ又はそれ以上のデータプロセッサ及び一つ又はそれ以上のデータプロセッサと結合するメモリを含み得るコンピュータシステムも、記載する。メモリは、少なくとも一つのプロセッサに、本明細書に説明する動作の一つ又はそれ以上を実行させる命令を、一時的に又は恒久的にストアし得る。さらに、方法は、単独のコンピュータシステム内部の、いずれか一つ又はそれ以上のデータプロセッサによって実装され、若しくは二つ又はそれ以上のコンピュータシステムの間で分配され得る。そのようなコンピュータシステムは、接続され得、並びにデータ及び／又はコマンド、若しくは他の命令などを、一つ又はそれ以上の接続、複数のコンピュータシステムの一つ又はそれ以上の間の直接接続を介して交換し得、一つ又はそれ以上の接続は、ネットワークを跨いだ接続（例えば、インターネット、無線ワイドエリアネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、有線ネットワーク、又はそのようなもの）を含むが、それらに限定されない。

本明細書に説明する発明の要旨は、多くの利点を提供する。例えば、本発明の要旨は、構造化フォーマットファイル（例えば、ＰＥフォーマットファイルなど）内部のコードから特徴を抽出するために用いられ得、そのような特徴は、次に、そのようなコードの潜在的な悪意のある形態を特定するために用いられ得る。

本明細書に説明される発明の要旨の一つ又はそれ以上の変形例の詳細は、添付の図面及び以下の説明に記載されている。本明細書に説明される発明の要旨の他の特徴及び利点は、説明及び図面から、及び請求項から、明白である。

図１は、ポータブル エグゼキュータブル フォーマットファイルを示す図である。 図２は、構造化ファイル内部のコード及びデータからの特徴の抽出を示す第１の処理フロー図である。 図３は、構造化ファイルからの抽出された特徴を示す図である。 図４は、構造化ファイル内部のコード及びデータからの特徴の抽出を示す第２の処理フロー図である。

様々な図内の類似の参照シンボルは、類似の要素を示す。

本発明の要旨は、構造化ファイルからの特徴抽出に関し、その特徴抽出は、公的に公式の文書が存在しないフィールド、及びＲＦＣ ４１２２ Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒｓ（アールエフシー ４１２２ ユニバーサリ ユニーク アイデンティファ）、Ｍｉｃｒｏｓｏｆｔ ＶｉｓｕａｌＢＡＳＩＣ（マイクロソフト ビジュアルベーシック）及び．ＮＥＴ Ｆｒａｍｅｗｏｒｋ（ドットネット フレームワーク）のコード及びデータ、並びにＭｕｌｔｉｌｉｎｇｕａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ（マルチリンガル ユーザ インターフェース）（ＭＵＩ）リソースなどの関連のある仕様（例えば、ＰＥ仕様など）においてカバーされない共通構造体のフィールドに加えて、構造化ファイルフォーマットの本質的に全ての文書化されたフィールドを、収集する。本発明の要旨は、構造化ファイル内部のコードの広がりを分析し、フィールドの様々なトークン化及びコードの導出を特徴として抽出するのにも用いられ得る。さらに、本発明の要旨は、どの特定可能なコード又はデータとも対応しない構造化ファイル内の「ネガティブスペース」から、特徴を導出することを可能にする。

本発明の要旨が、ポータブル エグゼキュータブル（ＰＥ）フォーマットファイルに対する本発明の要旨の利用例を説明する一方で、本明細書に説明される方法は、ＤＯＳ実行ファイル、ニュー エグゼキュータブル（ＮＥ）ファイル、リニア エグゼキュータブル（ＬＥ）ファイル、エグゼキュータブル アンド リンカブル フォーマット（ＥＬＦ）ファイル、ジャバ アチーブ（ＪＡＲ）ファイル、ショックウェーブ／フラッシュ（ＳＷＦ）ファイルなどの他のタイプの構造化ファイルに適用され得ることを理解されたい。構造化ファイルという用語は、本明細書に用いられるように、構造化ファイル内部でラップされる実行コードを管理するために実行環境によって要求されるデータをカプセル化するファイルのことを示す。

ファイルの静的な（不変の）内容が調べられるという点で、特徴抽出のこの処理は、静的分析と称されてもよい、実行中のその動的な（変化する）状態及び実行の副作用は考慮されない。ファイルは実行されないためである。静的分析は、しばしば、動的分析よりも、はるかに速く、はるかにリソース集約的でなく、及びより包括的であり、一方で動的分析は、実装することがより容易であり得、環境特有の情報のソースとして機器化されて存在する実行環境を使用し得る。

図１は、ポータブル エグゼキュータブル フォーマットファイルの一部を説明する図１００である。この図１００において、非公式に文書化された構造体の例（「Ｒｉｃｈ（リッチ）」データ）が含まれ、階層（例えば、ＩＭＡＧＥ＿ＮＴ＿ＨＥＡＤＥＲＳ −−＞ ＩＭＡＧＥ＿ＮＴ＿ＨＥＡＤＥＲＳ．ＯｐｔｉｏｎａｌＨｅａｄｅｒ −−＞ ＩＭＡＧＥ＿ＮＴ＿ＨＥＡＤＥＲＳ．ＯｐｔｉｏｎａｌＨｅａｄｅｒ．Ｍａｇｉｃ）及び順序（一連のＩＭＡＧＥ＿ＳＥＣＴＩＯＮ＿ＨＥＡＤＥＲ構造体）が提示される。他のタイプの構造化ファイルの構成は、内在する実行環境に基づいて異なり得る。例えば、ＤＯＳ実行ファイル、ＮＥファイル、及びＬＥファイルは全て、ＤＯＳヘッダから始まり、しかしＮＥファイルにおいては、ＤＯＳヘッダは、ＮＥ特有のヘッダを参照し、一方でＬＥファイルにおいては、ＤＯＳヘッダは、ＬＥ特有のヘッダを参照する。ＥＬＦファイルは、一方で、さらなるＥＬＦ特有のヘッダ及びテーブルを順次参照する独特のＥＬＦヘッダから始まる。

図２は、構造化ファイルからの特徴の抽出を説明する処理フロー図２００である。この特定の例において、構造化ファイルは、（メタデータ及びリソースを含む）データと共にコードを含むＰＥである。他の変形例は、他のタイプの構造化ファイルのために実装され得る。最初に、２０５において、ＰＥの処理は、（ローカル又はリモートソースからのいずれかの）第２の記録装置から読み出すことのためにＰＥファイルを開くことによって、若しくはＰＥファイルをダウンロードすること、別の方法で、ＰＥを構成するビットへのプログラムのアクセスを増やすことによって、始まる。その後、ＰＥへのアクセスは、バイトのストリームとして概念化される。図２の図２００においては、ＰＥをオープンすることが成功することが前提とされる。もし失敗する場合は、ＰＥはリジェクトされ得る。その後、２１０において、ＰＥファイルのＤＯＳヘッダが読み出され得る。ＤＯＳヘッダは、サイズが６４バイトの規定された構造体であり得、複数のフィールドを含む。読み出されたＤＯＳヘッダは、その後、２１５にて、チェックされ得る。もし６４バイト（又は他の予め規定された閾値）よりも少なく読み出された場合は、ＤＯＳヘッダの第１の部分（例えば、ＤＯＳヘッダの最初の２バイトを含むｅ＿ｍａｇｉｃフィールド）が、予測されたシグネチャを含まない、又はＤＯＳヘッダの第２の部分（例えば、ＤＯＳヘッダの６１番目から６４番目のバイトを含むｅ＿ｌｆａｎｅｗフィールド）が無効な値を構成する（例えば、それらがファイルの外側にオフセットを示す）ならば、ＰＥは、２３０において、リジェクトされ得る。もし、２１５において有効なＤＯＳヘッダが首尾良く読み出された場合は、その後２２０において、ストリームの読み出し位置は、ＤＯＳヘッダのｅ＿ｌｆａｎｅｗフィールドによって示される絶対位置に移動し得、ＰＥヘッダの第１の部分は、読み出される。ＰＥヘッダは、４バイトのシグネチャフィールド、２４バイトのファイルヘッダサブ構造体、及び可変長のオプショナルヘッダサブ構造体（このステップにおいて読み出されるように示されないが、近接するデータとして特定されて２３５にて読み出される。）を含み得る。次に、２２５において、２２０にて読み出されたＰＥヘッダの一部は、チェックされ得る。もし、２８バイトよりも少なく読み出された場合は、又はもしシグネチャフィールドが、予測されるシグネチャを含まない場合は、ＰＥは２３０にてリジェクトされ得る。もし、２１５又は２２５におけるチェックが充足しない場合は、その後の２３０にて、ＰＥは実際に有効なＰＥではないと判別されて、リジェクトされる。他のＰＥ検証ステップは、所望の実装に依存して利用され得る。

図２は、コード及びデータを読み出して構文解析し、さらなるコード及びデータをディスカバし得る、２３５から２８０までのループを含み得る。（ＰＥのいくつかの既知の位置において、ＰＥをスキャンすることによって見出される位置において、他のコード又はデータによって参照される位置において、若しくは他のコード又はデータに関する位置において）前もって見出された構造体は、２３５において、読み出され及び構文解析され得る。概念的に、ＤＯＳヘッダは、ルート構造体であり、０の既知の位置に位置付けられ、ＰＥヘッダを参照し、一方で、リッチデータは、（もし存在する場合は、）ＤＯＳヘッダに対して位置付けられる。ＰＥヘッダは、次に、他のコード及びデータを参照し又は他のコード及びデータに近接し、その他のコード及びデータは、他のコード及びデータを参照し又は他のコード及びデータに近接し、及びそのように続く。２３５の読み出し及びデータ特有の構文解析は、２４０において、続いてチェックされ得る。２４０におけるチェックが、２３５における読み出しが不完全であった又は失敗であったことを示すならば、又は２３５における構文解析が、データが無効であると判別したならば、続いて２４５にて、失敗又は無効についての情報は、そのデータに対して特徴として記録される。見出されたデータのキューは、その後、２５０において、チェックされ得る。もし、データは見出されたが、読み出し及び構文解析がまだ試行されていないならば、ループの別の繰り返しが２３５において始まり得る。もし２５０におけるチェックが、すべての見出されたデータが読み出されて構文解析されたことを示すならば、続いて２５５にて、コードスタートポイントはデータから、一般的には参照コードに知られているデータフィールドから、抽出され得る。しばしば、多くのコードスタートポイントの探索は、任意の単独のスタートポイントがＰＥ内のコードの一つのサブセットに唯一つながり得るので、ＰＥ内のすべてのコードを見出すために必要であり得る。続いて、２６０において、まだ探索されていない任意のコードスタートポイントは、逆アセンブリのためにスタートポイントとして用いられ得る。コードの多くの形式が逆アセンブリされ得、固有の機械語（例えば、ｘ８６、ｘ６４、又はＡＲＭ命令）、．ＮＥＴ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ（ドットネット インターミディエイト ランゲージ）及びＶｉｓｕａｌＢＡＳＩＣ ｐ−ｃｏｄｅ（ビジュアルベーシック ピーコード）を含む。２６０の逆アセンブリパスの間に見出されるコードスタートポイントは、その後、２６５において、考慮される必要のあるコードスタートポイントのセットに加えられ得る（データと同様に、勿論のことコードも、逆アセンブリされ得る前に、ＰＥから読み出される必要があり、またこれらの読み出しは失敗することもあるが、この考慮は図２から除外されている。）。未処理のコードスタートポイントのセットは、２７０において、チェックされ得る。もし、既知のスタートポイントのどれもが、逆アセンブリによってカバーされなかったならば、逆アセンブリループは、２６０において続き得る。逆アセンブリの間に見出されるデータ参照は、２７５において、データのキューに対して加えられ得、読み出され及び構文解析される。見出されたデータのキューは、２８０において（ちょうど２５０のように）チェックされ得る。もし、データは見出されたが、読み出し及び構文解析がまだ試行されていないならば、ループの別の繰り返しが２３５にて開始し得る。（実際のところ、再配置及び実行時間機能情報などのデータが利用可能にされているときに、特に逆アセンブリは改善されることが多いが、コード及びデータのディスカバリは、図２に示されるよりもより混合され得る。）

続いて、２８５において、全てのデータ及びコードは、構文解析されて逆アセンブリされたと想定され、よって、特徴が、抽出され得る。多くの場合において、特徴抽出は、コード及びデータがまだ見出されている間に実行されることではなく、ＰＥ内の全てのコード及びデータの包括的な把握を有することから利益を得る。

構造化ファイルフォーマット（例えば、ＰＥファイルフォーマット）において、データは、一般的に、トップレベルヘッダが別の構造体をカプセル化しながら階層的に配列され、別の構造体は別の構造体などをカプセル化し、及びそのように続く。データも、ファイルのデータの位置に従って、ほとんど常に、明確に順序付けられる。特定の順序付けが、仕様によって要求されることがあり、順序付けが、任意であることもある。階層及び／又は順序を明確に表現することが、冗長な又は望ましくない特別な場合はあるが、初期設定によって、本特徴抽出は、階層と順序の両方を維持する（図３を参照）。

図３は、１次のＰＥ特徴の表現を含む図３００であり、１次のＰＥ特徴の表現は、ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ジャバスクリプト オブジェクト ノーテーション）（ＪＳＯＮ）でフォーマットされている。図３００において、階層は、ＪＳＯＮオブジェクトを入れ子にすることによって表現されており、入れ子にされたフィールドは、「ＩＭＡＧＥ＿ＮＴ＿ＨＥＡＤＥＲＳ．ＯｐｔｉｏｎａｌＨｅａｄｅｒ．Ｍａｇｉｃ」などの階層を介したパスを記述する変数を介して参照され得る。順序は、ＩＭＡＧＥ＿ＳＥＣＴＩＯＮ＿ＨＥＡＤＥＲ構造体の配列などのＪＳＯＮ配列を用いて表現されている。実際のアウトプットにおいて、エリプシスの以下の領域ネームは、それらのフィールドの値によって置き換えられる。

いくつかの場合において、それは構造化ファイルから抽出された特徴を変換することは役立ち得る。変換の、一つの一般的なクラスは、サニタイズであり、サニタイズにおいて、予測できない及び一般的に信頼できないデータは、処理するためにより安全にされる。目標が（例えば、場合によっては不正な形式である構造化ファイルからの）潜在的な偽りのデータの手に負えない程の量を抽出することを避けることであるときは、そのデータは、合理的な最大値に切り詰められ、切り詰めの理由は特徴として留意され得る。切り詰めは、サイズチェックよりもより複雑な条件で、開始され得る。文字列の特徴抽出の場合において、例えば、文字列の構成が考慮され、印字不能文字、無効なエンコーディング、及び言語の混合をチェックする。用いられ得るサニタイズの別の形式は、一義的な可逆的な方法でデータをエスケープすること又はエンコードすることである。エンコードすることは、この点において、データが、システムの別のどこかにおいて特別な意味を持つ文字、又は必ずしも単独のユニコードのコードポイントを表現しないｒａｗバイトを含むときに、役立ち得る。

他の場合において、１次の特徴の代わりの表現は、その特徴が一般的にどう解釈されるかに関する知識を体系化するために提供され得る。例えば、もし単独の整数フィールドが、部分的に又は全体的に、（「ＩＭＡＧＥ＿ＮＴ＿ＨＥＡＤＥＲＳ．ＦｉｌｅＨｅａｄｅｒ．Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ」の場合にあるような）ビットフラッグを含むならば、それらのビットは、整数値の代わりに又は整数値に加えて、特徴（「Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ＿ｆｌａｇ１」、「Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ＿ｆｌａｇ２」、など）として抽出され得る。別の例において、フィールドの値は、比率として表現され得、結果的に得られる特徴が、任意のスケールの、整数の代わりの正規化された実数として表現されるように、第２のフィールド値又は一定の上界によって分割する。ハッシュ値を計算することは、（リソースデータのブロブなどの）潜在的に縛りのないデータ量を、予測された値のリストとの比較に適している少ない固定量に減少させる場合に用いられてもよい。

これらの１次の特徴は明確に有益であるが、特徴抽出は、１次の特徴及び構造化ファイルの他の基本的な内容を、高次の特徴へ処理することによってさらに改善され得る。一つの例においては、インポート変数の収集が辞書学的（あるＰＥファミリにおいて共通する特徴）に順序付けされ得るか否かは、ブールの特徴として表現され得る。一般的な機械学習アルゴリズムは、そのような順序付けが検出され及び重要性を有することを自動的に特定することを期待され得ず、したがって、このドメイン専門知識は、特徴を生成するロジックとして体系化され得る。別の例においては、構造化ファイルの要素の文字列のための正しいチェックサムが計算され、構造化ファイルのフィールドにストアされたチェックサムと対比され得、その二つが整合するかどうか及びそれらがどう異なるかの特徴として表現する（すなわち、要素は、ストアされたチェックサムが計算された後で、修正されたように見える。）。第３の例において、構造化ファイルからのタイムスタンプフィールドのセットは、有効なタイムスタンプの間のどれが最も初期のものであるかを判別するようにチェックされ得、及び、構造化ファイルが、最近のタイムスタンプによって表されるときに存在しなかった様々な機能に依存するかどうかが、ブールの特徴として表され得る。

機械学習モデルは、本明細書で用いられるように、インプットとしてサンプルの大きいセットを用いる様々な機械学習アルゴリズムを実行することによって訓練され得る。この考察の目的で、サンプルは、構造化ファイルから抽出される特徴のセットである。訓練の処理を通して、モデルは、すべてのサンプルが訓練セットの一部であったかどうかに関わらず、全てのサンプルを分類することの中でそれぞれの特徴の相対的な値を反映するに至る（ここで分類は、カテゴリ内にサンプルを位置付けることを示し、コンピュータセキュリティ事情においてカテゴリは、悪意のある／良性の、又はドロッパ／キーロガー／ランサムウェア／スパイウェア／ワームを含み得る。）。一般的に、モデルの精度（検出漏れの及び誤検出のエラーなどの誤分類の回避）は、できるだけ多くの代表的なサンプルから抽出される、できるだけ多くの品質特徴を機械学習アルゴリズムに供給することによって、しばしば改良され得る。したがって、特徴抽出は、ドメインの専門知識によって指示される他の特徴の処理に基づいた「高次」の特徴を含む、ファイルのｂｒｅａｄｔｈ（ブレドス）及びｄｅｐｔｈ（デプス）の至る所からの包括的な情報を示し得る。

図４は、構造化ファイルからの特徴の抽出を示す処理フロー図４００である。最初に、４１０において、構造化ファイル内部でラップされる実行コードを管理するために実行環境によって要求されるデータをカプセル化する構造化ファイルを含むデータは、受信され、又はその他の形でアクセスされる。その後に、任意で、４２０において、構造化ファイルが有効かどうか判別されても良い。もし構造化ファイルが有効でないと判別されたならば、分析／処理は終了され得る。そうでなければ、４３０において、構造化ファイル内部のコード及びデータは、繰り返し分析され（例えば、構文解析される、及び逆アセンブリされる、など）、１次の特徴を特定し及び抽出する。これらの１次の特徴は、続いて、４４０において、一つ又はそれ以上の変換技術を用いて変換される。さらに、４５０において、構造化ファイル内部のネガティブスペースは、分析されて、続いて抽出され得るさらなる特徴を特定する。抽出された特徴は、続いて、４６０において、高次の特徴が導出されるように、処理され得る。続いて、モデル（例えば、機械学習モデルなど）は、特徴を／特徴へのアクセスを提供され得る。

本明細書に説明される発明の要旨の一つ又はそれ以上の形態又は特徴は、デジタル電子回路、集積回路、特別に設計されたＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔｓ（特定用途向け集積回路））、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はそれらの組み合わせにおいて、実現され得る。これらの様々な実装は、少なくとも一つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能な及び／又は解釈可能な、一つの又はそれ以上のコンピュータプログラム内の実装を含み得、少なくとも一つのプログラマブルプロセッサは、特定の又は汎用の目的であり得、データ及び命令を、記録システム、少なくとも一つのインプットデバイス（例えば、マウス、タッチスクリーンなど）、及び少なくとも一つのアウトプットデバイスから受信するように、並びにデータ及び命令を、記録システム、少なくとも一つのインプットデバイス（例えば、マウス、タッチスクリーンなど）、及び少なくとも一つのアウトプットデバイスに送信するように、結合し得る。

これらのコンピュータプログラムは、プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリケーション、コンポーネント、又はコードと称されてもよく、プログラマブルプロセッサのための機械命令を含み、及び高レベルの手続き型言語、オブジェクト指向のプログラミング言語、関数型のプログラミング言語、論理型のプログラミング言語、及び／又はアセンブリ／機械言語で実装され得る。本明細書に用いられるように、（コンピュータプログラムプロダクトと称されるときがある）「機械可読型媒体」という用語は、例えば、磁気ディスク、光学ディスク、メモリ、及びプログラマブル論理デバイス（ＰＬＤｓ）などの物理的に統合された装置及び／又はデバイスのことを示し、機械命令及び／又はデータをプログラマブルデータプロセッサへ提供するのに用いられ、機械命令を機械可読型信号として受信する機械可読型媒体を含む。「機械可読型信号」という用語は、プログラマブルデータプロセッサへ機械命令及び／又はデータを提供するのに用いられる任意の信号のことを示す。機械可読型媒体は、例えば、非過渡のソリッドステートメモリ若しくは磁気ハードドライブ又は任意の同等の記録媒体であるように、持続的にそのような機械命令をストアし得る。機械可読型媒体は、代わりに又はさらに、例えば、一つ又はそれ以上の物理的なプロセッサコアが組み込まれたプロセッサキャッシュ又は他のランダムアクセスメモリであるように、一過的にそのような機械命令をストアし得る。

本明細書に記載する発明の要旨は、（例えば、データサーバとして）バックエンドのコンポーネントを含む、若しくはミドルウェアのコンポーネント（例えば、アプリケーションサーバ）を含む、若しくはフロントエンドのコンポーネント（例えば、グラフィカルユーザインターフェースを有するクライアントコンピュータ、又はユーザが本明細書に記載する発明の要旨の実装と作用するウェブブラウザ）、又はそのようなバックエンドの、ミドルウェアの、又はフロントエンドのコンポーネントの任意の組み合わせを含む、コンピュータシステムにおいて実装され得る。システムのコンポーネントは、デジタルデータ通信の任意の形式又は媒体（例えば、通信ネットワーク）によって相互接続され得る。通信ネットワークの例は、ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、及びインターネットを含む。

コンピュータシステムは、クライアント及びサーバを含み得る。クライアント及びサーバは、一般的にお互いから遠いところにあり、一般的に通信ネットワークを介して相互に作用する。クライアント及びサーバの関係は、個々のコンピュータ上で動作し、相互にクライアント−サーバの関係を有するコンピュータプログラムによって生じる。

本明細書に記載する発明の要旨は、システム、装置、方法、及び／又は所望の構成に依存する製品で具現され得る。前記述にて説明した実装は、すべての実装が本明細書に記載される発明の要旨と一致することを表す訳では無い。むしろ、それらは記載した発明の要旨に関する形態と一致する単なるいくつかの例である。いくつかの変形例は前述に詳しく記載されたが、他の改良又は追加は可能である。特に、さらなる特徴及び／又は変形例は、本明細書に記載されているそれらに加えて提示され得る。例えば、前述に記載した実装は、開示した特徴の様々な組み合わせ及び部分的な組み合わせ、並びに／又は、前記開示したいくつかのさらなる特徴の組み合わせ及び部分的な組み合わせ、に関する。さらに、添付の図にて示される、及び／又は本明細書に記載される論理フローは、所望の結果を達成するために、示される特定の順序又は連続する順序を必ずしも要求しない。他の実装は、以下の請求の範囲にあり得る。

Claims (16)

1. 構造化ファイル内部でラップされる実行コードを管理するために実行環境によって要求されるデータをカプセル化する構造化ファイルを含むデータを受信する又はデータにアクセスするステップと、
   構造化ファイル内のコード及びデータ領域を繰り返し特定するステップと、
   特定されたコード及びデータ領域の少なくとも一部を分析することによって、構造化ファイルから少なくとも一つの特徴を抽出するステップと、
   を含む方法。
2. 構造化ファイルは、ポータブル エグゼキュータブル（ＰＥ）フォーマットファイル、ディスク オペレーティング システム（ＤＯＳ）実行ファイル、ニュー エグゼキュータブル（ＮＥ）ファイル、リニア エグゼキュータブル（ＬＥ）ファイル、エグゼキュータブル アンド リンカブル フォーマット（ＥＬＦ）ファイル、ジャバ アチーブ（ＪＡＲ）ファイル、及びショックウェーブ／フラッシュ（ＳＷＦ）ファイルを含むグループから選択される、請求項１に記載の方法。
3. 実行環境は、オペレーティングシステム又はバーチャルマシンである、請求項１又は２に記載の方法。
4. 構造化ファイルが有効なシグネチャをカプセル化するかどうかを判別するために構造化ファイル内部の少なくとも一つのヘッダを調べることによって、構造化ファイルが有効であることを判別するステップをさらに含む、請求項１から３のいずれか一に記載の方法。
5. 抽出された少なくとも一つの特徴は、１次の特徴である、請求項１から４のいずれか一に記載の方法。
6. 抽出された少なくとも一つの１次の特徴を、高次の特徴の中へ導出するステップをさらに含む、請求項５に記載の方法。
7. 少なくとも一つのさらなる特徴を抽出するために構造化ファイル内部のネガティブスペースを分析するステップをさらに含み、ネガティブスペースは、特定されたコード及びデータ領域と異なる、請求項１から６のいずれか一に記載の方法。
8. 抽出された少なくとも一つの特徴を変換するステップをさらに含む、請求項１から７のいずれか一に記載の方法。
9. 変換するステップが、
   抽出された少なくとも一つの特徴をサニタイズするステップと、
   抽出された少なくとも一つの特徴を切り詰めるステップと、及び
   少なくとも一つの特徴の少なくとも一部をエンコードするステップと、
   のうちの一つ又はそれ以上を含む、請求項８に記載の方法。
10. 構造化ファイル内のコード及びデータ領域を特定するステップが、構造化ファイルを構文解析して逆アセンブリするステップを含む、請求項１から９のいずれか一に記載の方法。
11. 構造化ファイル内部のデータは、階層的に配置され、構造化ファイルは、第２のデータ構造体をカプセル化する第１のデータ構造体をカプセル化するトップレベルヘッダを含む、請求項１から１０のいずれか一に記載の方法。
12. 構造化ファイル内部のコード及びデータ領域を特定するステップは、構造化ファイル内のコード及び／又はデータ領域のタイプを特定するステップを含む、請求項１から１１のいずれか一に記載の方法。
13. 機械学習モデルに、抽出された少なくとも一つの特徴を提供するステップをさらに含む、請求項１から１２のいずれか一に記載の方法。
14. 機械学習モデルが、中間の処理するステップ又は構文解析するステップを介さずに抽出された少なくとも一つの特徴を消費する、請求項１３に記載の方法。
15. 命令をストアする持続性のコンピュータプログラムプロダクトであって、
    少なくとも一つのコンピュータシステムの一部を形成する少なくとも一つのデータプロセッサによって実行される際に、前記命令は請求項１から１４のいずれか一に記載の方法を実装するように稼働する、
    持続性のコンピュータプログラムプロダクト。
16. 少なくとも一つのデータプロセッサ、及び
    命令をストアするメモリを含み、命令は、少なくとも一つのデータプロセッサによって実行される際に、請求項１から１５のいずれか一に記載の方法を実装するように稼働する、
    システム。

Images