JP6563407B2 - 静的逆アセンブリからのａｐｉコールグラフの生成 - Google Patents

Description

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

本明細書に記載する発明の要旨は、プログラムコードの静的な逆アセンブリからのＡｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ（アプリケーション プログラミング インターフェース）（ＡＰＩ）コールグラフの生成に関する。

近年の実行環境において、プログラムは、一般的に、その自身用のプライベートバーチャルメモリの制御及びプログラムを実行する中央処理装置（ＣＰＵ）の非特権の状態を有するのみである。全体としてのシステムの状態を変更するために、そのプログラムは、ほぼ必ずＯＳから提供される明確に規定されたＡＰＩ関数をコールすることによって、プログラムの代わりにオペレーティングシステム（ＯＳ）が、稼働を実行することを要求しなければならない。プログラムによって実行されるＡＰＩコール、さらに、それぞれのコールで供給されるパラメータ及びそれぞれのコールの結果をキャプチャすることは、プログラムの振る舞いをプロファイルする単純な、簡潔な、効果的な手段である。
システムをプロファイルするほとんどのＡＰＩコールは、ＡＰＩコールをインターセプトして記録するために、一式のＯＳ導入、及びいくつかのユーザモード又はカーネルモードの機器を備えるバーチャルマシンにおいて、対象のプログラムを実行する。しかし、そのような動的な分析アプローチは、それぞれのバーチャルマシンに要求されるかなりの量のリソースを消費し、したがって、物理的なコンピュータ上で同時に動作し得るバーチャルマシンの数を著しく制限する。さらに、プログラムは、一般的に、リアルタイムに実行され、よってプログラムは、任意の重要なアクティビティを示す前に、発生するいくつかのイベント又は経過するタイムインターバルを待機することがある。このことは、システムが何分もそれぞれの対象のプログラムを動作することを強いられ、又はプログラムが実質的なＡＰＩコールを実行する前に停止する危険を冒し得ることを意味する。

Ｓｏｅｄｅｒ ｅｔ ａｌ．，「Ａｄｖａｎｃｅｄ Ｒｅｔｕｒｎ Ａｄｄｒｅｓｓ Ｄｉｓｃｏｖｅｒｙ Ｕｓｉｎｇ Ｃｏｎｔｅｘｔ−Ａｗａｒｅ Ｍａｃｈｉｎｅ Ｃｏｄｅ Ｅｍｕｌａｔｉｏｎ」，Ｊｕｌｙ ２００４

対象のプログラムをエミュレートする軽量な実装が、採用されてきた。しかしながら、エミュレータは、ＡＰＩの不完全な実装、及び現実の実行環境の振る舞いから検出可能な相違に悩まされることが多く、しかし、エミュレータは一般的に、サイズ及び速度の利点を提供する。エミュレータ及びバーチャルマシンの両方は、実行の単一の経路をプロファイルし得るにすぎないという重大な欠点に直面する。一般的に、エミュレータ及びバーチャルマシンの両方は、実行が潜在的にコードを介して続き得たかもしれない他の経路を考慮しない。

第１の形態において、プログラムの少なくとも一部を含むデータは受け取られる。続いて、プログラムのエントリポイント位置及び実行関連のメタデータは特定され検索される。プログラム内のコードの領域は、続いて、静的な逆アセンブリを用いて特定され、及び特定されたエントリポイント位置及びメタデータに基づく。さらに、エントリポイントは、複数の関数のそれぞれに対して判別される。続いて、可能性のあるコールシーケンスのセットは、コードの特定される領域及び複数の関数のそれぞれに対して判別されたエントリポイントに基づいて、それぞれの関数に対して生成される。

コールシーケンスは、アプリケーション プログラミング インターフェース（ＡＰＩ）コールを含み得る。コールシーケンスは、プログラムによって実行されるサブ関数をコールすることを含んでもよい。可能性のあるコールシーケンスの生成されるセットを特徴づけるＡＰＩコールグラフは、生成され得る。

コールシーケンス内のコールの少なくとも一つは、対応する関数の振る舞いに作用するパラメータ情報が付与され得る。

エントリポイント位置は、オペレーティングシステム又は他のプログラムがプログラムの実行を開始するプログラム内部の位置に対応し得る。

エントリポイント位置を特定して検索するステップは、一つの例として、予め規定されるバイトシーケンスについてプログラムをスキャンするステップを含み得る。

逆アセンブリは、例えば、エミュレーション拡張された逆アセンブリを含み得る。

相互関係を有する形態において、機械語を含むプログラムの少なくとも一部を含むデータが受け取られる。続いて、機械語は、命令に逆アセンブリされる。これらの命令は、続いて、コードブロックを含む関数に組成される。関数を特徴付ける制御フローグラフは、続いて、構成される。アプリケーション プログラミング インターフェース（ＡＰＩ）コールシーケンスは、次に、制御フローグラフを介して、いくつか又はすべての可能性のある経路をトラバースすることによって抽出される。続いて、ＡＰＩコール及び子関数コールの相対的な順序は、ＡＰＩコールグラフが、判別された相対的な順序に従って抽出されるＡＰＩコールシーケンスに基づいて、生成されるように、判別される。

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

本明細書に記載する発明の要旨は、多くの利点を提供する。例えば、本発明の要旨は、さらに多くの代表のＡＰＩコールシーケンスを生成する多くの場合において、従来の技術よりも大幅に高いコード網羅率を達成するプログラムから、ＡＰＩコールシーケンスを抽出することに対するアプローチを提供する。特に、本発明の要旨は、（利用可能な場合は、プログラムメタデータにより支援される、）静的な逆アセンブリを用いて、基本ブロックと関数レベルとの両方において、実行がされ得る可能な経路の制御フローグラフを構成する。この処理の最終結果は、実行がプログラムに入るポイントから開始して生じ得るＡＰＩコールのそれぞれの可能なシーケンスの簡潔な表現であり、所望のように及び可能性のある規模でキャプチャされるパラメータ値を伴う。

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

図１は、命令の様々なクラスの処理を示す処理フロー図である。 図２は、高水準言語のソースコードの例を示す図である。 図３は、図２に対応するコンパイルされたコードの構成要素ブロックを表す制御フローグラフを示す図である。 図４は、ＡＰＩコールグラフの生成を示す処理フロー図である。

最初に、所与のプログラム内部のコード（例えば、すべてのコード）は、静的な逆アセンブリを介して見出され得る（ディスカバされ得る）。この際の静的な逆アセンブリは、命令をデコードすること、並びにもし実行されたならば、命令が実行のフロー上に有する効果及び可能性のある効果を予測すること、の交互によって、プログラムのコードを構成する命令を繰り返しトラバースする処理を示す。プログラムは、ＯＳ又は別のプログラムが実行を開始し得る、一つ又はそれ以上の明確に規定されたエントリポイントを有する。したがって、一般的に、コードはこれらのエントリポイントに存在し得ることが、予測される。いくつかの場合において、コードのディスカバリは、共通のプロローグ又はよく知られた関数などのコードを一般的に表す、あるバイトシーケンスについてプログラムをスキャンすることによって改善され得る。コードの一部が複雑なランタイム状態から判別される実行の移転を介してのみ到達される状況において、共通のコードバイトシーケンスについてスキャンすることは、そのコードを見出すために、簡素かつ実に効果的な、静的な逆アセンブリに代わるものを提供する。一例として、後の実行のために、プログラムによってＯＳに供給されるバーチャル関数又はコールバックを考える。たとえ、静的な逆アセンブリが、関数へのポインタに直面しても、ポインタが関数ポインタとしてＯＳによって用いられることを認識し得ず、したがって、参照される関数を逆アセンブルし得ない。しかしながら、もし関数が、「ＰＵＳＨ ＥＢＰ／ＭＯＶ ＥＢＰ，ＥＳＰ／ＳＵＢ ＥＳＰ，ｉｍｍ」などの共通のプロローグから始まるならば、そのプロローグシーケンスについてプログラムをスキャンすることは、その関数及び適した他の同様な関数のディスカバリ及び連続的な逆アセンブリに至り得る。多くの場合において、プログラムは、コード又は実行関連のデータがプログラム内に存在することを記述するメタデータも含む。例は、６４ｂｉｔのネイティブのＷＩＮＤＯＷＳ（登録商標）プログラムにおけるランタイム関数情報、再配置、例外ハンドラ構造体、及びＭＩＣＲＯＳＯＦＴ（登録商標） Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ（マイクロソフト インターフェース ディフィニション ランゲージ）（ＭＩＤＬ）構造体を含む。

プログラムは、コードのチャンクに組み入れられたデータ及びパディングを含むことが多いので、逆アセンブリは、あるコードに知られたエントリポイント及び他の明確に規定された位置において開始し、同時に、一つの命令の連続するコードを見出す。例えば、ポータブル エグゼキュータブル ヘッダは、プログラムがロードされた後にＯＳによって実行されるプログラムエントリポイント、プログラムが他のプログラムに利用できるようにすることを目的とする関数又はプログラムエレメントを記述するエクスポートディレクトリ、ＯＳによって実行されるコールバック関数を記述するスレッドローカルストレージディレクトリ、ディレイインポートヘルパ関数を参照するディレイインポートディレクトリ、例外処理関数を参照する例外データなどを明確に規定し得る。ＲＰＣ（リモート プロシージャ コール）ランタイムによって実行される、ＲＰＣサーバ側の関数を参照するＲＰＣ関連の構造体などのコードを参照する他の構造体も、存在し得る。ほとんどの部分に対して、実行を明確にリダイレクトする分岐、コール及びリターン命令も存在するが、それぞれの命令は、それぞれの命令に即時に続く命令に、暗黙のうちに流入する。

図１は、どのように命令が実行に作用し得るか、したがってどのように逆アセンブリが命令に直面する上で続行すべきであるかによって、命令の様々なクラスをリストするダイアグラム１００である。特に、図１は、実行のフローにおけるそれらの影響によるｘ８６ファミリ命令のクラスの表現を示す。最初の差異は、命令が実行のリダイレクトを全くしない、時々する、又は常にする、のいずれかである。それは、当然、命令後に即時に逆アセンブリを継続する、又は、逆アセンブリが異なる位置で継続する、のいずれか、若しくは両方である。

図１のダイアグラム１００を再度参照すると、包括的命令１０５は、（逆アセンブリにおいて用いられるように）それに即時に続く命令（すなわち、プログラムカウンタは、命令の長さによってインクリメントされる。）に対する実行を暗黙のうちに通過する命令として規定され得る。（プロセッサ トラップ又はフォルトなどの）例外、又は他の割り込みによる実行の移転の可能性は、図１に示されていない。無条件の関連する分岐命令１１０は、一方で、関連する分岐命令に関連しているデスティネーションに、明確に命令を移転し得、従って、次の命令に対する実行を暗黙のうちに通過しない。間接分岐命令１１５は、明確に実行を移転してもよく、一方で、デスティネーションは、分岐命令にて明確にエンコードされるのではなく、システムの状態から検索される。このことは、一般的に、逆アセンブリの間に判別するにあたり、デスティネーションを自明でないものにする。条件付きの関連する分岐命令１２０は、それ自身に対するデスティネーションに明確に実行を移転し得、又は次の命令に対する実行を暗黙のうちに通過し得る。ＣＰＵフラグレジスタの状態は、二つの可能性のどちらが実現されるかを制御することができ、したがって、関連する条件付きの分岐命令のデスティネーションが、次の命令と同等である場合を除いて、静的な逆アセンブリの間に判別することは、自明ではなく、さらに不可能ともなり得る。関連するコール命令１２５は、関連する分岐命令のように、それ自身に関連するデスティネーションに、明確に実行を移転し得、しかし、スタック上にそれ自身に即時に続くアドレス（すなわち、命令の長さをプラスした命令のアドレス）をプッシュしてもよい。コール命令のデスティネーションが、コールに続くアドレスにリターンする関数のエントリポイントであることは、逆アセンブリのために一般的に想定され得、しかし、これは厳密に保証されない。例えば、「ｎｏ ｒｅｔｕｒｎ（ノー リターン）」関数は、実行を返さず、したがって、コンパイラは、そのような関数へのコール後に、即時に、データ又は関連しないコードを配置することがある。

間接コール命令１３０は、関連するコール命令と同じやり方でそれ自身に即時に続くアドレスをプッシュしている間に、間接分岐命令と同じやり方で命令を明確に移転し得、したがって、両方の警告を受けることになる。このために、ソフトウェア中断命令（示されない）は、概念的に、間接コール命令に等価である。リターン命令１３５は、スタックのトップからポップされるアドレスへ命令を移転し得る。これは、一般的に、コール命令に即時に続く命令のアドレスであり、しかし、間接分岐命令のデスティネーションのように、このアドレスは、システムの状態によって決まり、逆アセンブリの間に判別するために重要であり得る。最後に、ハルト命令１４０は、全く実行を移転しない。中断が生じるまで、ハルト命令に留まる。

それぞれのタイプの命令に関するこの基礎知識を用いて、静的な逆アセンブリは、プログラムエントリポイントから到達可能なプログラムコード又は任意の他の特定可能な命令の範囲をカバーする制御フローグラフを一般的に生成するが、その制御フローグラフは、ランタイム状態に依存するが故に静的な逆アセンブリの間に簡単に予測できない実行フローにおけるそれらの遷移を除外するものである。この場合の制御フローグラフは、それぞれの命令がノードであり、それぞれの可能な実行の移転がエッジである有向グラフを示す。効率性のために、それぞれのノードは、実行の単一経路のみがある一つ又はそれ以上の命令のブロックを代わりに表し得る。前記示したように、しかしながら、完全にトラバースし損なう実行において遷移があり得るので、静的な逆アセンブリは、完全な制御フローグラフを構築することにおいて、必ずしも成功し得ない。そのような遷移の一つの困難な例は、間接分岐、間接コール、及びリターンのトラバースである。特別な場合のロジックは、いくつかのそのような状況を処理し得る。インデックスを付された静的なテーブル（例えば、「ＪＭＰ［ｔａｂｌｅ＋ＥＡＸ＊４］」）を使用する分岐及びコールの可能性のあるデスティネーションは、インデックスを制限する近隣の命令をチェックすることによって、及び有効なポインタ（特に、再配置でマークされたポインタ）についてテーブルメモリを調べることによって、誘発されることが多い。

コールは、さらに捉えにくい課題を示す。コール命令の後に逆アセンブリを継続することは直感的に思えるが、すべてのコーリーがそれに供給されるリターンアドレスへ実行をリターンするとは限らない。ここで、連続する検索に対する命令ポインタをプッシュすることが意図されている「ノー リターン」関数及びコールは、特定されることがあり、最も単純な場合の関係するコール命令の後に、適した非コードに逆アセンブリすることを避けることができる。

実行が単一の命令の範囲外の情報から影響される状況をより良く処理するために、逆アセンブラは、命令及びＡＰＩコールについての、エミュレーションとしての理解により、拡大し得る。エミュレーションの欠点を回避するために、この機能は、大抵は、他には無いであろう場所に情報を伝達するために用いられ得る。例えば、エミュレーションを有さない逆アセンブリは、「ＣＡＬＬ ＥＢＸ」命令のターゲットを識別せず、しかしエミュレーションを有する逆アセンブリでは、ＥＢＸレジスタが、特有の関数ポインタを事前にロードしたことをトラックし得る。一般的に、エミュレーションは、非コードの逆アセンブリを回避することに役立ち得るが、どの実行の経路が探索されるかを制限するために用いられるべきではない。

本エミュレーションと併せて、ポインタに関する特別な記号の検討（非特許文献１を参照のこと。非特許文献１の文脈は、参照の上、全体として本明細書に組み込まれている。）を伴う（もし不定であれば、それぞれのビットの状態が、０、１、又はＸとして維持される）整数の３変数を持つ表現、及び値がＳａｔｉｓｆｉａｂｉｌｉｔｙ Ｍｏｄｕｌｏ Ｔｈｅｏｒｙ（サティスフィアビリティ モジュロ セオリ）（ＳＭＴ）解法によって単純化を可能とする演算式として維持される完全シンボリックエミュレーションの両方を、検討する。エミュレーションのそのような形式は、より包括的なコード網羅率、ＡＰＩ関数コールのより良いトラッキング、及びＡＰＩコールに供給されるパラメータのより良いトラッキングを提供し、それらの三つすべては、情報（特に関数ポインタ）のより強力な伝達によって促進される。

説明目的のために、一つの例の関数を、四つの形式で示す。四つの形式は、そのオリジナルの高水準言語ソースコード（図２のダイアグラム２００）、（以下にリストされる）ｘ８６命令へのコンパイルされた関数の逆アセンブリ、コンパイルされたコードの構成ブロックを表す制御フローグラフ（図３のダイアグラム３００）、及び関数が実行するためのポテンシャルを有する（以下にリストされる）ＡＰＩコールシーケンスである。特に、図２のダイアグラム２００は、以下のＷＩＮＤＯＷＳ（登録商標） ＡＰＩコールであるＣｒｅａｔｅＦｉｌｅＷ、ＣｌｏｓｅＨａｎｄｌｅ、ＧｅｔＦｉｌｅＳｉｚｅ、ＤｅｌｅｔｅＦｉｌｅＷ、ＬｏｃａｌＡｌｌｏｃ、ＬｏｃａｌＦｒｅｅ、及びＲｅａｄＦｉｌｅを用いるＣ＋＋で記述される関数を示す。

以下は、Ｘ８６命令へコンパイルされる際の、図２のダイアグラム２００の関数のアセンブリ言語のリストである。逆アセンブリは、分岐命令後に、分岐デスティネーションにおいて、基本コードブロックに分割される。それぞれの命令は、属するコードブロックを示す括弧内の文字で、注釈を付される。

図３は、前記逆アセンブリの基本コードブロックの有向グラフ３００である。もしコードブロックがいずれかのＡＰＩコールを実行するならば、コールされるＡＰＩ関数の名前は、対応する矩形内に現れる。グラフは、ブロックＩ、Ｊ及びＫを跨ぐサイクル（ループ）を含むことに留意すべきである。

以下は、図２のダイアグラム２００の例の関数において可能性のあるすべてのＡＰＩコールシーケンスである。ＲｅａｄＦｉｌｅ ＡＰＩコールは、ループの実行の間に繰り返し生じ得るため、アスタリスクでマークされている。

プログラムが機械語を含むと仮定して、本アプローチでは、コードを命令に逆アセンブルし、続いて、本アプローチでは、命令を、基本コードブロックを含む関数に組成する。内部関数のレベルにおいて、制御フローグラフの構成は、ループ内部に生じるが不定のトラバースを避けるために経路毎に２回以上はブロックを訪問しないＡＰＩコールがどれであるか留意しつつ、グラフを介してすべての可能性のある経路を徹底的にトラバースすることによって、ＡＰＩコールシーケンスの抽出をすることができる。アプローチは、続いて、全体のプログラムについて、ノードが関数を表し、及びエッジが他の関数（又は自分自身）をコールする一つの関数を表す有向グラフであるコールグラフを生成し得る。

コールグラフは、関数の間のコールを表すが、この情報だけでは、すべての関数間のＡＰＩコールシーケンスの正確な再構築を可能にするには十分ではない。子関数コール及びＡＰＩコールの相対的な順序はキャプチャされる必要がある。例えば、もし関数ｇがＡＰＩ Ａ、関数ｆ、及びＡＰＩ Ｂをコールし、並びに、もし関数ｆがＡＰＩ Ｃをコールするならば、関数ｇのためのコールシーケンス「Ａ ｆ Ｂ」及び関数ｆのためのコールシーケンス「Ｃ」は、維持され得る。その結果、前者のシーケンスは、「Ａ Ｃ Ｂ」に適正に展開され得る。非ＡＰＩ関数コールがコールシーケンスに含まれていないならば、関数ｇがＡＰＩコールシーケンス「Ａ Ｂ」を有し、関数ｆをコールすることがあることのみを示すコールグラフが残され、関数ｆはそうするとＡＰＩコールシーケンス「Ｃ」を有することになるが、「Ａ Ｂ」、「Ａ Ｂ Ｃ」、「Ａ Ｂ Ｃ Ｃ」、「Ａ Ｃ Ｂ」、「Ａ Ｃ Ｂ Ｃ」、「Ｃ Ａ Ｂ」などの間のどのシーケンスが実際に生じうるのか不明確となってしまう。

すべての関数コールシーケンスは、ＡＰＩコールシーケンスの網羅的なセットに展開され得るが、考えられるシーケンスの数は、実行不可能な程に大きくなり得る。その代わりに、ＡＰＩコールシーケンスのこの簡潔な表現は、維持され、及びアルゴリズムは、関数ごとのＡＰＩコールシーケンス内に又は関数ごとのＡＰＩコールシーケンスの間に、ＡＰＩコールｎグラムを探すことが考えられ得る。

より記述的なＡＰＩコールシーケンスを生成するために、ＡＰＩコールは、利用可能なときのパラメータ情報を付与され得る。前記の例に戻ると、前記リストされたＡＰＩコールは、以下のように付与され得る。

維持されるパラメータ情報は、ＡＰＩ関数の振る舞いに影響を与える限りにおいてのみ、又は合理的に包括的なフィンガープリントとしての機能を果たすことにおいてのみ、具体的であるべきである。例えば、ＡＰＩ関数は、あるスタック位置に対する参照によりコールされることに注目することは、過度に具体的である。プラットフォームを跨いで、さらに同じコードの再コンパイルの間にて変更する可能性があるためである。その一方で、ＣｒｅａｔｅＦｉｌｅＷに引き継がれるアクセスマスク、又はＧｅｔＰｒｏｃＡｄｄｒｅｓｓに引き継がれる関数名などの他のパラメータ値は、プログラムが所与のＡＰＩ関数をコールすることのために有し得る可能性のある意図の間の差別化要因として有益である。

図４は、ＡＰＩコールグラフの生成を示す制御フローダイアグラム４００である。最初に、４１０において、プログラムの少なくとも一部を含むデータが受け取られる。続いて、４２０において、プログラムのエントリポイント位置及び実行関連メタデータは、特定され検索される。続いて、静的な逆アセンブルを用いる４３０において、コードの領域は、特定されたエントリポイント位置及びメタデータに基づいて、プログラム内部で特定される。次に、４４０において、エントリポイントは、複数の関数のそれぞれに対して判別され、その結果、４５０において、可能性のあるコールシーケンスのセットは、複数の関数に対して判別されたエントリポイントに基づいて、それぞれの関数に対して生成される。

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

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

ユーザとの相互作用を提供するために、本明細書に記載する発明の要旨は、例えば、ユーザに対して情報を表示するためのｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ（ブラウン管）（ＣＲＴ）、又はｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ（液晶ディスプレイ）（ＬＣＤ）モニタなどの表示装置、及びキーボード、及び例えばマウス又はトラックボールなどのポインティング装置、を有するコンピュータ上で、実行され得る。キーボード及びポインティング装置により、ユーザはインプットをコンピュータに提供し得る。他の種類の装置は、同様にユーザとの相互作用を提供するために用いられ得る。例えば、ユーザに提供されるフィードバックは、例えば、視覚的なフィードバック、聴覚的なフィードバック、又は触覚的なフィードバックなどの感覚のフィードバックの任意の形式であってよく、ユーザからのインプットは、任意の形式で受け取られ得、任意の形式は、聴覚、発話、又は触覚インプットを含むが、それらに限定されない。他の可能なインプット装置は、タッチスクリーン、若しくは単一ポイントの又は複数ポイントの抵抗性の又は容量性のトラックパッドなどの他のタッチセンシティブ装置、音声認識ハードウェア及びソフトウェア、光学スキャナ、光学ポインタ、デジタル画像キャプチャ装置、並びに組み込まれた解釈ソフトウェアなどを含むが、それらに限定されない。

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

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

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

Claims (9)

1. プログラムの少なくとも一部を含むデータを受け取るステップと、
   プログラムのエントリポイント位置及び実行関連のメタデータを特定して検索するステップであって、エントリポイント位置はオペレーティングシステム又は他のプログラムが実行を開始するプログラムの少なくとも一部分の内部の一つまたは複数の位置に対応し、実行関連のメタデータはコード又はコードの領域がプログラム内に存在するところを記述する、特定して検索するステップと、
   特定されたエントリポイント位置及びメタデータに基づいて、プログラム内部のコードの領域を、逆アセンブリを用いて特定するステップと、
   複数の関数のそれぞれに対してのエントリポイントを判別するステップと、
   複数の関数に対して判別されたエントリポイントに基づいて、それぞれの関数に対する可能性のあるコールシーケンスのセットを生成するステップと、
   実行中にプログラムの少なくとも一部が取ることができる可能な経路を推測することを可能にするために、可能なコールシーケンスの生成されたセットを特徴付ける関数コールグラフを生成するステップと、
   を含む実行中にプログラムの少なくとも一部が取ることができる可能な経路を推測するためのコンピュータが実行する方法。
2. コールシーケンスは、アプリケーション プログラミング インターフェース（ＡＰＩ）コールをさらに含む、請求項１に記載の方法。
3. コールシーケンスは、プログラムによって実行されるサブ関数をコールすることをさらに含む、請求項２に記載の方法。
4. 対応する関数の振る舞いに作用するパラメータ情報を、コールシーケンス内のコールの少なくとも一つに付与するステップをさらに含む、
   請求項１から３のいずれか一に記載の方法。
5. エントリポイント位置を特定して検索するステップは、
   予め規定されるバイトシーケンスについてプログラムをスキャンするステップを含む、
   請求項１から４のいずれか一に記載の方法。
6. 逆アセンブルが、エミュレーション拡張された逆アセンブリを含む、請求項１から５のいずれか一に記載の方法。
7. 機械語を含むプログラムの少なくとも一部を含むデータを受け取るステップと、
   機械語を命令に逆アセンブリするステップであって、逆アセンブリすることは、オペレーティングシステム又は他のプログラムが実行を開始するプログラムの少なくとも一部分の内部の一つまたは複数の位置に対応する特定されたエントリポイント位置に基づき、かつ、コード又はコードの領域がプログラム内に存在するところを記述する実行関連のメタデータに基づく、逆アセンブリするステップと、
   命令を、コードブロックを含む関数に組成するステップと、
   関数を特徴付ける制御フローグラフを構成するステップと、
   制御フローグラフを介して、すべての可能性のある経路をトラバースすることによって、アプリケーションプログラミングインターフェース（ＡＰＩ）コールシーケンスを抽出するステップと、
   ＡＰＩコール及び子関数コールの相対的な順序を判別するステップと、及び
   判別された相対的な順序に従って抽出されるＡＰＩコールシーケンスに基づいて、ＡＰＩコールグラフを生成するステップと、
   を含む方法。
8. 命令をストアする持続性の機械可読型媒体であって、
   少なくとも一つのコンピュータシステムの一部を形成する少なくとも一つのデータプロセッサによって実行される際に、前記命令は請求項１から７のいずれか一に記載の方法を実装するように稼働する、
   持続性の機械可読型媒体。
9. 少なくとも一つのデータプロセッサ、及び
   命令をストアするメモリを含み、命令は、少なくとも一つのデータプロセッサによって実行される際に、請求項１から７のいずれか一に記載の方法を実装するように稼働する、
   システム。

Images