JP5458184B2 - 動的ファンクションコールシステムにおけるアグレッシブな自動修正のためのシステムおよび方法 - Google Patents

Description

本発明は、一般に、コンピュータセキュリティの分野に関連する。より詳細には、本発明は、ファンクションコールシステムの制御フロー難読化のための方法およびシステムに関する。

難読化は、ソフトウェアコードのリバースエンジニア、コピーまたはタンパリング（以降タンパリングと称する）を複雑にすることによりソフトウェアのタンパリングを防止または遅延させる変換である。多くの場合、ソフトウェアコードのタンパリングは、遅延させるだけで十分で、ソフトウェアが、通常完了に数秒しかかからない金融取引を保護するアプリケーションである場合、特に十分である。著作権があるものの場合、タンパリングプロセスにかかる時間を十分に長くし、ソフトウェアを正規のコピーに比べて、極端に費用がかかるようにしておけば、難読化は成功である。

ソフトウェアのタンパリングには、主に２種類の攻撃が存在する。すなわち、静的攻撃と動的攻撃である。静的攻撃には、パーシャルエバリュエータ等を用いてソフトウェアを実行せずに静的に解析することを含む。動的攻撃には、メモリ内で実行されるコードを監視しかつリフティングして、リフティングした部分をキャプチャしてコードを再構成することを含む。

動的攻撃では、ファンクションコール、コールサイトならびに入口点および出口点が、攻撃者にとってプログラムの制御フローを解析し、そのコールグラフを回収するための戦略的ターゲットである。

既存の制御フローの難読化方法は、基本的にブランチとジャンプを含むローカル制御フローに適用される。これは、関数スコープに限定される。より大きな侵入の脅威は、コードのリフティングや再実装を可能にする、攻撃者によるコール構造の発見能力である。従来の呼び出しの約束についてはよく理解されているため、ファンクションコールのバウンダリ（ｂｏｕｎｄａｒｙ）が攻撃しやすいポイントになっている。

既存の自動修正コード技術は、主にデータオペレーションを行う直線命令ブロックに適用される。これは、オペレーションを隠す助けになり得る一方で、アプリケーションのマクロ制御レベルを隠すためにはほとんど役立たない。

Ｃ++のようなより高水準の抽象的言語の広範な使用では、アプリケーションはより低水準の言語の等価なアプリケーションに比べて、一般により多くの関数とより深い呼び出しツリーを有する。これは、現在、アプリケーションの関数バウンダリがより高いリスクにさらされていることを意味する。

たとえば、エケル他のＰＣＴ国際出願公開第２００８／０７４４８３Ａ1号公報（ここに全文を引用により援用）は、コンピュータプログラムの難読化について記載するが、たとえばデバッガを使用する、コードリフティング攻撃、動的およびステップ攻撃については扱っていない。

エケルらの文献は、アドレスを計算する方法を変更することによりファンクションコールシステムを修正する方法を開示する。修正されたファンクションコールは、実行時に代数式により計算される。その結果が、実行時に決定される関数のアドレスによるコールバイポインタファンクションコールである。

この方法は、コードリフティング攻撃からコールグラフを保護する能力を有していない。たとえば、関数定義本体が修正されることはない。簡単に静的にリフティングされ、他のプログラムで悪用され得る。また、デバッガまたは監視プログラムを使用する動的攻撃においては、ファンクションコールシーケンスが、ステップバイステップで追従されて、コードリフティングおよび／またはタンパリングのための対象の呼び出された関数を見つけられてしまう可能性がある。

また、エケルらの発明によれば、静的コールサイトは、コールバイポインタで置き換えられる。それでも、それらは依然としてコールサイトのままである。コールサイトであれば、その独自の命令の特徴により攻撃者の有用なブレークポイントとして識別されてしまう可能性がある。攻撃者が、すべてのコールサイトは、その独自の命令の特徴により攻撃者にとって有用なブレークポイントとして識別され得る。攻撃者がすべてのコールサイトをブレークし、プログラムを実行するとすれば、動的手段によってコールグラフ情報を回収することができる。

２００７年発行の、マシアス・マドウによる「プログラム難読化によるアプリケーションセキュリティ（Application Security through Program Obfuscation）」と題する刊行物（ここに全文を引用により援用）は、その第５章で、データオペレーションを変更することにより命令レベルで行われるいくつかの技術を組み合わせるトレース難読化の方法を記載する。これらの技術には、多様なコードの挿入、コードファクタリングおよび難読化述語の挿入を含む。

多様なコードの挿入は、命令が存在する基本ブロックに向かって取られる経路に基づき、命令を複数の等価な命令の１つで上書きするために使用される。

コードファクタリングは、１つの命令だけが異なるコードの２つの条件ブロックを合体させる技術である。コードからなる合体ブロックへ至る条件経路には、１つの命令が上書きされて、実行される直前に正しい挙動を提供する。

第３の技術は、多様性を作り出すために、難読化述語を構成しかつこれらをコードに挿入することを含む。述語は、偽に評価したり真に評価したりする条件を有する。述語の後続部は等価だが、多様なコードを有する。

マドウの技術は、上記３つの技術すべてを組み合わせて、プログラムのトレース難読化を行うためのものである。しかしながら、マドウによる多様性技術は、データ命令の修正に限定される。難読化述語の挿入は、その挙動が予め定められたブランチの挿入のみを含む。

さらに、マドウのシステムでは、関数が呼び出されて実行されるシーケンス、順序、時期および態様が同じままである。したがって、動的攻撃は、マドウの方法で保護されるソフトウェアに対しては、依然として成功する可能性がある。

また、マドウの方法は、静的攻撃に対してはプログラムを保護しない。分離された関数は依然としてその全体に渡ってリフティングが可能であり、リフティングをされた後も継続してその元の態様で挙動する可能性がある。

したがって、プログラムのコールグラフの包括的な変換を行う、静的および動的攻撃に対抗する制御フロー難読化のための方法およびシステムの提供が求められる。

本発明の目的は、プログラムを静的および動的攻撃から保護するための、プログラムの包括的な変換を含む保護方法を提供することである。

本発明の実施例によれば、方法は、プログラムを変換するため、元のプログラムのファンクションコール構造、ファンクションコールグラフ全体およびファンクションコールレイアウトという３つのプログラム特性を理解する複雑な予備解析ステップを含む。実施例において、プログラムの変換は、構築時の関数に関連する命令の動的挿入、置換および修正の編成を含んでもよく、それにより変換されたプログラムの静的解析（静的攻撃）は、適切なファンクションコールレイアウトを示さずかつメモリで実行する際のプログラムの挙動も表示しない。構築時に計画された動的変更が、実行時に実行され、それにより変換されたプログラムの実行を監視する動的攻撃では、メモリで実行される変換されたプログラムの適切なファンクションコールグラフまたはファンクションコールレイアウトの判別は成功しない。

ある局面において、本発明は、ソフトウェアプログラムを静的および動的攻撃から保護するために、プログラムの制御フロー構造を変更することによって、プログラムを元の形式からよりセキュアな形式へ変換する方法を提供する。この方法は、プログラムの元のファンクションコール構造およびファンクションコールレイアウトを解析するステップと、元のファンクションコールレイアウトを新しいレイアウトに変換するステップと、元のファンクションコール構造を、動的自己修正を実行することができる新しい構造へ変換するステップと、変換された制御フロー構造を有するが意味的には元のプログラムと等価な変換されたプログラムを生成するステップと、プログラム実行の際に元のファンクションコールグラフを新しいファンクションコールグラフに変換するステップとを含む。

この文脈では、「意味的に等価」という用語は、「同じ結果または出力を生成する」ことと解釈する。

実施例において、動的自己修正により関数が呼び出される時期と態様が変更される。元のプログラムの解析および変換ならびに変換されたプログラムを生成するステップを、構築時に行い、かつ元のコールグラフを新しいグラフに変換するステップを、実行時に行ってもよい。プログラムの元のレイアウトおよび構造を変更するステップには、ファンクションコールレイアウトを偽装するための関数バウンダリを変更するステップを含んでもよい。実施例では、関数バウンダリを変更するステップには、関数バウンダリを壊して、２つ以上の関数を１つの関数に結合するステップを含んでもよい。他の実施例では、関数バウンダリを変更するステップが、新たな関数バウンダリを挿入して関数を２つ以上の関数に分割するステップを含む。

方法は、プログラムにダメージを行うステップをさらに含み、そのダメージが、ファンクションコール構造をさらに偽装しかつ元のプログラムに対して機能的等価性を維持するための１以上のフィックスアップダメージにより追随される１以上の改変性のダメージを含んでもよい。

実施例において、元のプログラムを解析するステップが、プログラムを修正するためのプログラムにおける戦略ポイントを決定しかつ／または複雑な予備解析工程を行って、プログラムのファンクションコール構造、ファンクションコールレイアウトおよびファンクションコールグラフ全体を理解するステップ含む。修正ポイントが、対応の実行ポイントから物理的かつ時間的に遠いポイントに配置されてもよい。実施例において、１つの実行ポイントについて複数の修正ポイントを設ける。

他の局面では、本発明は、静的および動的攻撃からプログラムを保護するために、プログラムの制御フロー構造を変更することにより、ソフトウェアプログラムを元の形式からよりセキュアな形式に変換する方法を提供する。この方法は、構築時フェーズと実行時フェーズを含む。構築時フェーズは、プログラムの元のファンクションコール構造およびファンクションコールレイアウトを解析するステップと、プログラムの元のファンクションコールレイアウトを新しいファンクションコールレイアウトに変換するステップと、ファンクションコール構造を動的修正を行うことができる新しいファンクションコール構造に変換するステップと、変換された制御フロー構造を有するが、意味的には元のプログラムに等価な変換されたプログラムを生成するステップとを含む。実行時フェーズが、プログラムの実行に際して、プログラムの元のファンクションコールグラフを新しいファンクションコールグラフに変換するステップを含み、実行時に行われる動的修正が、構築時に行われる変更に相補的で、元のプログラムに対して意味的に等価な変換されたプログラムを生成する。

さらに他の局面では、本発明は、ステートメントおよび命令を記録したコンピュータ可読メモリを提供し、これは、ソフトウェアプログラムを動的および静的攻撃から保護するためプログラムの制御フロー構造を変更することにより、プログラムを元の形式からよりセキュアな形式に変換するためのものであり、前記ステートメントおよび命令は、プロセッサにより実行されると、プロセッサが、プログラムの元のファンクションコール構造およびファンクションコールレイアウトを解析するステップと、元のファンクションコールレイアウトを新しいレイアウトに変換するステップと、元のファンクションコール構造を、動的自己修正を行うことができる新しい構造に変換するステップと、変換された制御フロー構造を有するが、元のプログラムに意味的には等価な変換されたプログラムを生成するステップと、プログラムの実行に際して、元のファンクションコールグラフを新しいファンクションコールグラフに変換するステップとを実行する。

本発明の他の局面および特徴については、添付の図面とともに以下の本発明の特定の実施例の説明を参照すれば、当業者には明らかになるであろう。

本発明の実施例について、添付の図面を参照し、もっぱら例示を目的として、以下に説明する。
元の形式のプログラムの従来のファンクションレイアウト、コールグラフおよびファンクションコールシーケンスを示す図である。 本発明の実施例により、図１に示すプログラムが変換されたバージョンを示す図である。 図２の変換されたプログラムの実行時プロセスおよび動的修正を示す図である。 本発明の実施例により、すでに実行された命令について、プログラムにダメージを施すことができる方法の例を示す図である。 図１に示す元のプログラムのコールシーケンスと図２、図３ａおよび図３ｂに示す変換されたプログラムの動的コールシーケンスを対比して示すフロー図である。 （ａ）から（ｃ）は、本発明の実施例による、メインエントリ関数以外の関数を有していないプログラムのための動的コールシステムを実装する場合の実行時プロセスを示す図である。 本発明の実施例によるプログラムを変換するステップを示すフローチャートである。 従来のシステム上で実行するためのアプリケーションプログラムを構築するために使用する従来のツールのセットを示す図である。 本発明の実施例による動的ファンクションコールシステムにおいて使用される構築ツールの例を示す図である。 本発明の実施例による、元のプログラムを、静的および動的攻撃に対してセキュアな保護されたプログラムに変換するためのシステムの例示的実施例を示す図である。 動的ファンクションコールシステムのための代替的オペレーションセットアップを示す図である。 動的ファンクションコールシステムのための代替的オペレーションセットアップを示す図である。 動的ファンクションコールシステムのための代替的オペレーションセットアップを示す図である。

本発明の実施例は、プログラムを第１の形式から静的および動的攻撃に耐性があるよりセキュアな形式に変換するためのソフトウェア難読化のためのシステムおよび方法を提供する。実施例において、この方法は、プログラムを変更するためのプログラムにおける戦略的ポイントを判別するため、プログラムのファンクションコール構造、ファンクションコールレイアウトおよびファンクションコールグラフ全体を理解する複雑な予備解析ステップを使用する。この方法は、元のファンクションコールレイアウトを新たなレイアウトに変換することにより静的攻撃に対する耐性を付与する。実施例において、レイアウトの変更は、関数バウンダリを変更することを含んでもよい。この方法はまた、元のファンクションコール構造を、変換されたプログラムをメモリで実行すると自己修正することができる新しい構造に変換することにより静的攻撃に対する耐性を付与する。実施例において、ファンクションコール構造の変更は、関数を呼び出す時期と方法を修正することおよび／または同じ結果に至る実行のランダムな経路を選択することを含んでもよい。変換されたプログラムは、意味的には元のプログラムと等価でも、静的および動的攻撃に対してより耐性のあるものになる。

これ以降の説明において、ファンクションコールグラフ、ファンクションコール構造、ファンクションコールレイアウトおよび制御フロー構造は、以下のように解釈する。

・ファンクションコールグラフとは、プログラムをメモリ内で実行する際に、関数の識別と実行のために呼び出される関数の態様、順序、時期、および継続時間との関係である。ファンクションコールグラフは、通常ハッカーが動的攻撃を行うために監視する。

・ファンクションコール構造は、実行の際のプログラムの挙動を決定する構造である。関数の構造を構成するプログラムコード、バウンダリ、入力／出力の約束および呼び出しの約束ならびに関数が呼び出され実行される方法および時期を含む。

・ファンクションコールレイアウトは、プログラムがストアされ、実行されていない時、静的観点から、ファンクションコール構造がどのように見えるか、すなわち、関数の数、順序、およびバウンダリ他である。ファンクションコールレイアウトは、攻撃者がコードリフティングおよびタンパリング等の静的攻撃を行うために調べるものである。

・制御フロー構造は、プログラムを介する制御の変更を可能にするオペレーションのセットである。ローカルレベルでは、これには、ブランチとジャンプとが含まれる。プログラムレベルでは、制御フロー構造は、ファンクションコール構造、ファンクションコールレイアウト、ジャンプおよびブランチ、リターン、スレッディングならびに例外処理が含まれる。

本発明の実施例によれば、プログラムの変換は、以下の２つのフェーズを含む。

・構築時−実行前にプログラムを静的に解析し変更する時。このフェーズには、戦略ポイントを決定するためのプログラムの解析ならびにデコイの挿入、新関数の創出、ファンクションコールの挿入、関数バウンダリ等の変更およびファンクションコール構造の変更によるプログラムの変換を含む。

・実行時−変換されたプログラムをメモリ内で実行する時。新しいファンクションコール構造は、自己修正を行いかつファンクションコールグラフを変更する。プログラムが実行されると、関数が呼び出される時期と方法が修正されることにより、ファンクションコールグラフ全体が、修正される。

本発明の実施例によれば、方法は、元のプログラムのファンクションコール構造、ファンクションコールグラフ全体およびファンクションコールレイアウトの３つのプログラム特性を理解するための複雑な予備解析ステップを含む。実施例において、上記のマドウの発明のように、もっぱらブランチレベルのみでデータ命令を変更する場合とは異なり、方法はプログラム全体のレベルで制御フローを考える。プログラムが元のままでかつ難読化や隠されていない場合には、予備解析ステップによって、対応のファンクションコールグラフおよび関数バウンダリのための適切なファンクションコール構造を検出することができる。したがって、プログラムがその元の形式である場合は、これら３つのプログラム特性が互いに一致する。

本発明の実施例によれば、プログラムの変換は、構築時の関数関連の命令の動的挿入、置換および修正の編成を含む。したがって、プログラムが構築時に変換された後は、変換後のプログラムにおいて、３つのプログラム特性は、いずれも相互に一致しない。変換されたプログラムは、新しいファンクションコール構造と、新しいファンクションコールレイアウトを有する。言い換えれば、プログラムの適切なファンクションコール構造は、静的または動的攻撃を行うことによってはもはや判別することができない。特に、変換されたプログラムの静的解析（静的攻撃）では、適切なファンクションコールレイアウトを表示しないので、メモリで実行されるプログラムの挙動も表示しない。その後も、静的攻撃では、変換されたプログラムの適切なファンクションコール構造を表示できない。一方で、メモリにおける変換されたプログラムの実行を監視する動的攻撃は、監視するファンクションコールグラフからは、変換されたプログラムの適切なファンクションコール構造も、ファンクションコールレイアウトの判別にも成功しない。これは、変換されたプログラムが、メモリで実行される際に、自己修正を行うからである。この修正には、異なる順序、異なる時期で関数を実行することと、同じ結果に至る実行のランダムパスを選択することとを含んでもよい。したがって、変換されたプログラムは、静的および動的攻撃に対してよりセキュアであり、かつ適切なファンクションコール構造はよりよく保護される。

好ましい実施例では、変換された制御フロー構造は、新しいファンクションコールレイアウトおよび新しいファンクションコール構造を含む。他の実施例では、変換されたファンクションコール構造は、ジャンプおよびブランチ、例外ならびにリターンのうち１つ以上を含んでもよい。

変換されたプログラムをメモリで実行する場合、プログラムレベルでは、プログラムの実行を監視する攻撃者は、適切なファンクションコールグラフを検出できないし、元のプログラムの適切なファンクションコールレイアウトや構造も判別できない。したがって、攻撃者は、非常にローカルなレベル、すなわちコードの現在の実行ポイントで、プログラムの実行を監視するにとどまると考えられる。しかしながら、プログラムレベルでは、攻撃者は、たとえプログラムコードの全実行ポイントについての情報を収集しても、プログラムを再構成することはできない。これは、変換されたプログラムの制御フローおよびファンクションコールグラフが、元のプログラムのものとは異なるためである。

変換されたプログラムをメモリで実行しながら、元のアプリケーションのファンクションコール、リターンステートメント、関数入口点およびファンクションレイアウトバウンダリが動的に変化して、プログラムの作者が意図する元のファンクションコールシステムを静的および／動的攻撃から隠す。こうして、静的解析または動的解析いずれによる場合も、プログラムのタンパリングの容易性は低減される。

ファンクションコールレイアウトは、関数間のバウンダリを壊すかまたは変更することにより新しいファンクションコールレイアウトに変換することができる。結果として、攻撃者は、実行時、動的攻撃を用いて関数の入口および出口を判別することができず、またプログラムがストアされている場合、静的攻撃を用いて変換されたプログラムのファンクションコール構造またはファンクションコールレイアウトを判別することができない。これは、プログラムのファンクションコールレイアウトが偽装されているからである。関数本体に対するこれらの修正により、攻撃者が、完全無傷の関数本体をリフティングする危険性が低減される。

関数本体内のコールサイトも、削除または挿入を含めて修正することが可能である。新たな関数を創出して、新しいコールサイトを用いて呼び出してもよい。コールサイトは、静的には明白になっていない。これらのサイトは、実行時に動的に挿入され得る。さらに、コールサイトがプログラムに挿入されるポイントは、その呼び出しが行われる時期とは無関係である。たとえば、実行時、プログラムは、何らかの呼び出しが行われる前に、プログラムに１００を超える数の異なるコールサイトを挿入したり削除したりすることが可能である。実施例では、コールサイトを挿入または削除する時期および態様ならびに関数が呼び出される時期を変更可能である。たとえば、関数への呼び出しを遅延させ、他のコードでコールサイトを置換し、いくつかの関数他より先に呼び出し、これまでに行われたまたはこれから行おうとしている呼び出しの証拠を隠し、実行の順序を変更することが可能で、またこれらの技術を組み合わせることもできる。

従来のファンクションコールリターンＡＢＩ（アプリケーションバイナリインターフェース、Ａｐｐｌｉｃａｔｉｏｎ-Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ）は、アプリケーションがメモリ内で実行されている時に修正され得る新しいＡＢＩへ変換される（実行時プロセス）。また、構築時（セキュリティ要素および反タンパリング技術が保護対象のアプリケーションに適用される時）に関数の複製を構築して、実行時に複数のコードパスが出来るようにする。

構築時、プログラムは、ファンクションコールの約束のバウンダリが動的に修正され得るようにセットアップされる。これらの関数バウンダリは、コールサイト、リターンポイント、エントリ命令、関数の開始および終了等を含む。本発明の実施例では、非決定論を用いてコールグラフによる実行の経路をランダムに選択しており、一方、確実に元のプログラムに意味的に等価になっている。非決定論は、有効な結果に至る複数の経路の１つをランダムに選択するアルゴリズムである。

実施例において、変換されたプログラムを、これが実行される場合は常に異なるファンクションコールグラフを得るよう設定する。こうして、メモリにおける変換されたプログラムの実行を監視する攻撃者は、異なる実行時に異なる結果を得ると考えられる。しかしながら、どの時期に得られた結果でも、攻撃者を元のプログラムの正確なファンクションコール構造またはレイアウトには導かない。

変換されたプログラムを介して実行が進むと、命令は動的に修正され、それによりコールサイトおよび関数バウンダリは、実行の前後で変更される。本発明の実施例では、命令が修正される（挿入、削除または変更される）プログラムのポイントが、修正された命令が実行される前または後の適切なポイントで発生する。修正された命令の実行に先立って発生する修正点については、修正がどれほど早くまたは遅く発生するかが問題ではなく、修正が命令実行に先だって生じることだけが重要である。

本発明の他の実施例では、命令がどのように修正されているかを攻撃者に識別さないようにかつまた修正と修正された命令の実行との関係を判別することができないように、修正ポイントは、少なくとも１命令分対応の命令から離されている。したがって、対応する実行ポイントから物理的に離れたポイントに修正ポイントを置くこと、たとえば間に他の実行点または他のコードを挟んだりすることが好ましい。

実施例において、修正ポイントを、アナライザ／コンパイラが、対応の実行ポイントの前に実行されるとわかっている関数内に置くことにより、対応の実行ポイントから修正ポイントを離してもよい。この解析を、支配関係解析と呼ぶ。修正ポイントは、実行ポイントと一対一対応でなくてもよい。これらは、多数対一または一対多数でもよい。たとえば、ある実行ポイントに到達する前に、追従するいくつかの修正ポイントを設けてもよい。

この方法は、ファンクションレイアウトおよびコールシーケンスを静的系の侵入（ディスアセンブリ、デコンパイラ等）から隠し、ファンクションレイアウトおよびコールシーケンスを動的系の侵入（デバッガ、エミュレータ等）から隠しかつコードリフティングおよびタンパリング攻撃をより困難にすることにより、不正使用の攻撃に対する耐性を付与する。その結果、新しいファンクションコールレイアウトおよび新しいファンクションコール構造を含む新しい制御フロー構造を有する変換されたプログラムが得られる。変換されたプログラムは、元のプログラムに意味的には等価だが、同時にタンパリング、コードリフティングならびに静的および動的攻撃に対してより耐性がある。

図１は、元の調整がされていない形式のプログラムまたはアプリケーションの従来のファンクションレイアウト、コールグラフおよびファンクションコールシーケンスの例である。直線的な従来のシーケンスで、各関数が呼び出され、実行されリターンされる。図１に示すように、元のコールシーケンスは以下のとおりである。すなわち、システムがＭａｉｎを呼び出し、ＭａｉｎがＦｕｎｃｔｉｏｎ＿１を呼び出すことにより実行を開始、Ｆｕｎｃｔｉｏｎ＿１がＦｕｎｃｔｉｏｎ_２を呼び出し、Ｆｕｎｃｔｉｏｎ＿２がＦｕｎｃｔｉｏｎ＿１をリターン、その後、Ｆｕｎｃｔｉｏｎ＿１がＦｕｎｃｉｔｏｎ＿４を呼び出し、Ｆｕｎｃｔｉｏｎ＿４がＦｕｎｃｔｉｏｎ＿１をリターン、その後、Ｆｕｎｃｔｉｏｎ＿１がＭａｉｎにリターンし、Ｍａｉｎがシステムにリターンする。

図２は、本発明の実施例による図１に示すプログラムの変換されたバージョンを示す。図示のプログラムは、構築時後の、変換され「プリロードされた」プログラムである。図２に例示する変換後のプログラムは、あるファンクションコールシーケンスを有するように見えるが、実行時にコードが動的に修正されるため、実際には別のファンクションコールシーケンスを実行する。構築時、多くのコード操作準備ステップを実行し、その中には、実行時にコード修正を簡素化する新しいＡＢＩで従来のファンクションコールの約束を置換するステップと、レイアウトを偽装するよう関数バウンダリを修正するステップと、コールサイトポイントをデコイコール、デコイ命令等で修正するステップと、ストレートライン命令をコールサイトで置換するステップと、複製関数を挿入するステップと、付加的関数を挿入するステップとを含む。

図２に示すとおり、新しいｃａｌｌ ｆｕｎｃｔｉｏｎ＿５を創出して挿入し、かつ以前のｃａｌｌ Ｆｕｎｃｔｉｏｎ＿２（図１に示す）は削除されている。Ｆｕｎｃｉｔｏｎ＿１のバウンダリも、ｃａｌｌ Ｆｕｎｃｔｉｏｎ＿４をＦｕｎｃｔｉｏｎ＿３へのコールサイトで置換することにより元のＦｕｎｃｔｏｎ＿１を修正済みＦｕｎｃｔｉｏｎ＿１および新Ｆｕｎｃｔｉｏｎ＿３に分割し、かつＦｕｎｃｔｉｏｎ＿３内にＦｕｎｃｔｉｏｎ＿４へのコールサイトを挿入することにより、変更されている。上記の手段は構築時に行われ、攻撃者の目を、真のファンクションコールレイアウトおよび呼び出し構造からそらす役割をする。

図３ａは、図２の変換されたプログラムの実行時プロセスおよび動的修正の例を示す図である。変換プログラムを実行すると、修正ポイントはファンクションコール特性を変更する。修正ポイントがいくつかのコード部分を修正して、プログラムの適正な実行を確実に行いかつ攻撃者から情報を隠すためいくつかのコード部分にダメージを与える。構築時と実行時との間で行われるこれらの相補的変更により、元のプログラムと意味的には同様でも、攻撃者を混乱させる異なるファンクションコール特性を有する変換されたプログラムが得られる。

図３の例では、ｍａｉｎが実行を開始、続いてＦｕｎｃｔｉｏｎ＿１、これが次にＦｕｎｃｔｉｏｎ＿５を呼び出す。元のプログラムではＦｕｎｃｉｔｏｎ＿５は発生しなかったが、構築時のプログラム解析の際にコンパイラにより挿入されている。Ｆｕｎｃｔｉｏｎ＿５は、図２に示す通り、構築時図１に示す元のプログラムからは削除されたＦｕｎｃｔｉｏｎ＿２へのコールサイトを挿入することによりＦｕｎｃｔｉｏｎ＿１の修正を行う。制御がＦｕｎｃｔｉｏｎ＿１に戻ると、Ｆｕｎｃｔｉｏｎ＿２が呼び出され、これが、Ｆｕｎｃｔｉｏｎ＿３への呼び出しからの次のコールサイトをＦｕｎｃｉｔｏｎ＿４への呼び出しに修正することによりＦｕｎｃｔｉｏｎ＿１の修正を行う。Ｆｕｎｃｉｔｏｎ＿４が呼び出されると、Ｒｅｔｕｒｎをｎｏ ｏｐｅｒａｔｉｏｎ（ＮＯＰ）でかつＣａｌｌ Ｆｕｎｃｔｉｏｎ＿４をＮＯＰで置換することによって、Ｆｕｎｃｔｉｏｎ＿１とＦｕｎｃｉｔｏｎ＿３との間のバウンダリが削除され、Ｆｕｎｃｔｉｏｎ＿１を再び図１の元のプログラムにあるような１つの大きな関数にする。制御は、Ｆｕｎｃｉｔｏｎ＿１に戻り、そしてｍａｉｎに戻る。

静的および動的攻撃に対してよりセキュアな制御システムを編成するために、同様の方法により動的にダメージを発生させることができる。プログラムへのダメージは、プログラムを改変し、不正確に機能させるプログラムに対する修正である。図２および図３ａに例示される動的変更とダメージの差は、動的変更の場合、変換されたプログラムが実行の際にいずれの時期においても静的に十分に正しいが、予期しない態様で実行される。対照的に、図３ｂにあるような改変性のダメージを含む保護されるプログラムは、改変性ダメージの後は、後に実行時に改変性のダメージを治すフィックスアップ修正が発生するまで不正確に（プログラムの作者が意図したとおりではない等）実行される。

フィックスアップ修正は、対応する改変性ダメージから変換されたプログラムを訂正し、確実に元のプログラムに意味的に等価にする。図２および図３ａに示す修正と同様、ダメージは、構築時に計画されかつ実行時に実行される。本発明の実施例において、１つの改変性ダメージについて１を超える数のフィックスアップ修正を有することができる。ダメージとそれらの対応するフィックスアップ修正は、これらに限定されるわけではないが、以下の複数の目的のために役立つ。

１．すでに実行された命令を隠す。
２．後の実行のため命令の状態を準備する。
３．さらなるダメージおよび／または修正のためプログラムを準備する。

図３ｂは、すでに実行された命令について、プログラムにどのようにダメージを施すことができるかの例を示す図である。プログラムが、解析システムが計画した通りにすでにコードのいくつかのセクションを実行したと仮定して、プログラムの真のコール構造を難読化するために使用するダメージを発生させることができる。図３ｂを参照して、Ｆｕｎｃｔｉｏｎ＿１が実行を開始したポイントであり、Ｆｕｎｃｔｉｏｎ＿２が実行を終了したポイントであり、Ｆｕｎｃｔｉｏｎ＿４が実行を開始したポイントであるポイント３００を考える。Ｆｕｎｃｔｉｏｎ＿４は、次の２つのダメージを行う。

１．Ｆｕｎｃｔｉｏｎ＿４における命令（またはいくつかの命令のセット）が、すでに発生した関数への呼び出し（Ｃａｌｌ Ｆｕｎｃｔｉｏｎ＿２等）を削除する。

２．また、Ｆｕｎｃｔｉｏｎ＿４は、元のプログラムに発生していないＦｕｎｃｔｉｏｎ＿６への呼び出しを挿入する。

第１のダメージによりＦｕｎｃｔｉｏｎ＿４が呼び出されたとする証拠が削除され、かつ第２のダメージによりさらなるダメージを発生するＦｕｎｃｔｉｏｎ＿６への呼び出しを挿入する。

Ｆｕｎｃｔｉｏｎ＿６への呼び出しに到達すると、Ｆｕｎｃｉｔｏｎ＿６が４つのフィックスアップ修正を実行する。

１．Ｆｕｎｃｔｉｏｎ＿６が、元のプログラムに発生しなかったＦｕｎｃｔｉｏｎ＿５への呼び出しを挿入する（第１のステップでは、Ｆｕｎｃｔｉｏｎ＿５が自動修正に使用されることを想起されたい）。

これは、後の起動のためのプログラムの状態の準備である。

２．Ｆｕｎｃｔｉｏｎ＿６が、Ｃａｌｌ ｔｏ Ｆｕｎｃｔｉｏｎ＿４を修正して、Ｃａｌｌ ｔｏ Ｆｕｎｃｔｉｏｎ＿３になるようにする。

３．Ｆｕｎｃｔｉｏｎ＿６が、すでに実行されているので、自己への呼び出しを削除する。

４．Ｆｕｎｃｔｉｏｎ＿６は、Ｆｕｎｃｔｉｏｎ＿１にリターンステートメントを挿入することによりＦｕｎｃｔｉｏｎ＿３バウンダリを挿入し、Ｃａｌｌ ｔｏ Ｆｕｎｃｔｉｏｎ＿４を挿入することにより、効果的にＦｕｎｃｉｔｏｎ＿１のレイアウトに終了をかつＦｕｎｃｉｔｏｎ＿３のレイアウトに開始を作り出す。

ダメージのすべてと対応するフィックスアップ修正が発生した後、変更されたプログラムにおける実行の結果は、図２に示す構築時に予め計画した修正と調和のとれたものになる。言い換えれば、ダメージのすべておよびフィックスアップ修正の発生後も、元のプログラムに対する意味的な等価性が維持される。図３ｂは、構築時に実行される予備修正と調和するように、プログラムのコール構造に対してダメージおよびフィックスアップ修正がどのように行われ得るかの一例のみを示す図である。

動的変更および／またはダメージを実装するコードが、変更されたプログラムに挿入される。コードは、関数の形をとるか、適切なプログラム内のいくつかのコードとして挿入され得る。コード自体は、ホワイトボックス暗号、データ変換、完全性検証または類似の技術を使用して保護される。同一所有者による米国特許第７，３９７，９１６号および米国特許出願第１１／０２０，３１３号および米国特許出願第６１／１７５，９４５号（ここに全文を引用により援用）を本発明のプログラム内のコードを保護するために使用してもよい。

図４は、図１に示す関数の元のコールシーケンスを、図２および図３ａに示す変換されたプログラムの動的コールシーケンスと対比して示すフロー図である。図４に示すとおり、Ｍａｉｎがｆｕｎｃｔｉｏｎ１を呼び出しした後、メモリにおいて実行されると変換されたプログラムの挙動が動的に変化する。例えば、動的コールシーケンスにおいて、Ｆｕｎｃｔｉｏｎ＿５は、Ｆｕｎｃｔｉｏｎ＿１の後でかつＦｕｎｃｔｉｏｎ２の前に呼び出されており、元のコールシーケンスでは、Ｆｕｎｃｔｉｏｎ＿５は、存在していない。上記のとおり、Ｆｕｎｃｔｉｏｎ＿５は、構築時に挿入される。さらに、Ｆｕｎｃｔｉｏｎ＿２は、ｃａｌｌ ｆｕｎｃｔｉｏｎ＿４をｃａｌｌ Ｆｕｎｃｔｉｏｎ＿３で置換することによりＦｕｎｃｔｉｏｎ＿１を修正する。Ｆｕｎｃｔｉｏｎ＿３は、図１および図２に示す元のＦｕｎｃｔｉｏｎ＿１の一区分である。Ｆｉｇｕｒｅ＿１を図１にあるような元の大きさにするため、Ｆｕｎｃｔｉｏｎ＿４は、実行時にＦｕｎｃｔｉｏｎ＿１とＦｕｎｃｔｉｏｎ＿３との間のバウンダリを取り除き、これにより構築時に実行した変更を修正する。

図４に示す実施例において、関数は修正され、様々な時期に様々な態様で呼び出され、関数バウンダリは変更され、かつ新しい関数が導入され削除される。

保護されるプログラムの実行を監視する攻撃者は、以下のものを入手すると考えられる。

・見せかけの関数および見せかけのファンクションコールレイアウト。これは、たとえば関数の出入口を変更することにより関数バウンダリが変更され、いくつかの関数が複製され、かつ元のプログラムに含まれていないいくつかの関数が、システムにより創出され得るからである。

・各関数の見せかけの実行時間。これは、関数が予め遅延または呼び出しをされ得るためである。

・見せかけの実行順序。これは、元のプログラムと比較すると、いくつかの関数が他の関数より前に実行され得るからである。

・見せかけのファンクションコールグラフ。これは、関数が分けられかつ／または結合され、かつたとえば非決定論を用いるなどして、ランダムな実行経路を選択でき、元のプログラムと機能的な等価性は維持するものの、メモリで実行する際には異なって見えるためである。

図５（ａ）は、図５（ａ）に示すＭａｉｎエントリ関数以外の関数を有していないプログラムのための動的コールシステムを実装する際の実行時プロセスを示す。実行時、このプログラムを解析して、プログラムを動的に変化するプログラムに変換するための戦略ポイントを決定する。図５（ａ）に示す、Ｍａｉｎ内のＦｕｎｃｔｉｏｎ＿Ａのためのバウンダリ、入口、出口およびコールサイトを作ることにより、Ｍａｉｎのバウンダリが実行に伴い変更される。図５（ｂ）に示す通り、Ｆｕｎｃｔｉｏｎ＿Ａを実行した後で、Ｆｕｎｃｔｉｏｎ＿Ａのバウンダリ、コールサイトおよび出入口を削除する。

図５（ｃ）に示す通り、Ｆｕｎｃｔｉｏｎ＿Ａのバウンダリ、コールサイトおよび出入口は実行の後削除されており、Ｍａｉｎは、変換がまるでなかったかのように見える。しかしながら、攻撃者の視点からは、タンパリングが成功していないことになる。これは、見せかけのコールグラフ情報を提供されているはずだからである。

他の極端な例では、静的に過剰な数の関数を有するようにプログラムをセットアップすることが考えられる。実行時、関数バウンダリが、より大きな関数に組み込まれる一方で、元のプログラムと意味的には等価な変換されたプログラムを提供する。

図６は、本発明の実施例に従い、プログラムを変換するステップを示すフローチャートである。図６に示す通り、ステップ６００で、保護対象のもとのプログラムを解析して、ファンクションコール構造およびファンクションコールレイアウトを理解する。ステップ６０２で、メモリにストアされた際に、攻撃者が静的に解析すれば、変換後のプログラムが異なって見えるように、元のファンクションコールレイアウトを新しいレイアウトに変更する。ステップ６０４で、ファンクションコール構造を、変更されたプログラムの実行の際に動的自動修正ができる新しいファンクションコール構造に変換する。ステップ６０６で、ステップ６０４および６０６で予め計画した変更に従って、メモリにおけるプログラムの実行の際に、元のファンクションコールグラフを新しいグラフに変換する。

関数のコールサイト、リターンポイント、エントリ命令、開始および終了等の関数バウンダリを動的に修正してより大きいまたは小さい関数にできるようプログラムを変換する。関数バウンダリ内のコールサイトも削除または挿入を含む修正を行うことができる。関数バウンダリを実行の前後で変更して、静的および動的攻撃に抵抗する。関数複製、デコイおよび追加の命令を挿入して静的および動的攻撃がより困難になるようにする。

ステップ６０８で、元のプログラムと意味的に等価な変換されたプログラムを生成する。保護されるプログラムは、静的に解析すると元のプログラムとは異なっており、メモリで実行される際に自己修正して、動的攻撃およびコードリフティングに抵抗することができる。

実施例では、プログラムの変換の前に元のプログラムを解析して各関数について重要性のレベルを決定し、セキュリティの目的または性能の目標について重要な関数を強調することにする。

セキュリティ目的については、ある関数がセキュアなアセットを含むかまたはトラストキーのルート（ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｋｅｙ）等のセキュリティシステムの重要な部分を計算し得るので、ユーザがこれを重要として識別することができる。これは、その関数がセキュリティ的観点から重要である旨表示するために、言語拡張またはコマンドラインインターフェース等の外部手段を介して行ってもよい。この場合、変換システムはこの特定の関数について、難読化の作業を強調することができる。

性能目的では、コンパイラで静的プロファイリングまたは実プロファイリング手段でしばしば実行される関数を識別することができる。性能に関する考慮を重要とするいくつかの実施例においては、実行の頻度が高い関数については、素早く実行することが知られている変換をその関数用に選択することが考えられる。

図７は、ネイティブシステム上で実行するためのアプリケーションプログラムを構築するために使用される従来のツールのセットを示す。この場合に使用される主要なツールは、コンパイラとリンカであり、これらは、従来は２つの別々のツールであるが、同じツールに組み合わせることができる場合もある。また、これらを、２を超える数のツールに分けられる場合もある。コンパイラの主要な機能は、アプリケーションプログラムファイルの構文および意味解析を行い、最適化を行いかつリンカのためのコードを生成することである。リンカは、プログラムおよびデータセグメントを、組み合わせられると実行に必要なバイナリファイルまたはバイナリファイルのセットを形成するレイアウトに配置転換する。実行は、ヴァーチャルマシン上でネイティブまたはヴァーチャル化することができる。

図８は、本発明の実施例に従う動的ファンクションコールシステムにおける構築ツールの例を示す図である。図８は、図７に示す従来のツールに対する２つの新しいツール、すなわちコンパイラレベルの解析ツールとリンクレベルの解析ツールとを示す。コンパイラレベルの解析ツールは、従来のコンパイラレベルの処理と関連しており、ネイティブコンパイラの前後に独立してまたは従来のコンパイラの代替物として実行され得る。また、これは、ネイティブリンカまたはネイティブリンカの代替物の前後に独立して実行することもできる。図８に示すように、コンパイラレベルの解析ツールは、ネイティブコンパイラの前に実行される。同様に、リンクレベルの解析ツールは、リンクレベルの処理と関連する。また、これは、ネイティブリンカの前後に独立してまたはネイティブリンカの代替物として実行することができる。

コンパイラレベルでは、アプリケーションプログラムのフルファンクションコールグラフを解析して、「メイコール」（ｍａｙ−ｃａｌｌ）および「マストコール」（ｍｕｓｔ ｃａｌｌ）表現で表すことができる。これらのコール表現をその後、グローバルに解析して命令の挿入、削除および修正を割り振ることができる。元のプログラムは、動的修正のためにコンパイラレベルで戦略的に修正される。

関数バウンダリを解析し、リンクレベルでの消費に備えて、情報を準備することが可能である。リンクレベルでは、プログラムセグメントは、どの関数を相互にまたどの順序で隣接させる必要があるかを含むコンパイラレベルから伝達されるレイアウト情報に従い配置する。これにより、関数バウンダリの動的修正を行うことができる。さらに、追加の静的ライブラリおよび／またはオブジェクトコードをブログラム内にリンクさせて、命令修正等の副次的オペレーションを行う。リンクレベルでは、動的修正システムに必要なコンポーネントは、実行可能なバイナリまたはバイナリセットで配置される。

図９は、プログラムのファンクションコールレイアウトを変更しかつそのファンクションコール構造を、プログラム実行時に動的に自己修正できる新しい構造に変換することにより、プログラムを元の形式から静的および動的攻撃に対抗してよりセキュアな形式に変換し、それによりメモリにおける変換されたプログラムの実行を監視する攻撃者に、見せかけのファンクションコールグラフを与えるようにするためのシステム９００の実施例を示す。

図９に示す実施例において、システム９００は、少なくとも２台のコンピュータ９０２および９０４を含む。コンピュータ９０２は、ＣＰＵ９０６、メモリ９０８、図８に示す構築ツール９１０のセットおよび入力出力モジュール（Ｉ／Ｏ）９１２を含む。コンピュータ９０４は、ＣＰＵ９１４，メモリ９１６およびＩ／Ｏ９１８を含む。コンピュータ９０２は、変換対象の元のプログラムを受けて、構築時プロセスを実行して、プログラムのファンクションコールレイアウトおよびファンクションコール構造を変更する。変換されたプログラムは、次にコンピュータ９０４へ転送されてストアおよび／または実行される。変換されたプログラムは、コミュニケーションリンクまたはＣＤ、ＤＶＤおよびＵＳＢドライブ等のコンピュータ可読メモリまたは何らかの他の手段によりコンピュータ９０４へ転送されてもよい。

変換されたプログラムは元のプログラムと意味的には等価だが、静的および動的攻撃に対してよりセキュアである。変換されたプログラムは、コンピュータ９０４上にストアされ、ファンクションコールレイアウトが、元のプログラムの真のレイアウトを反映していないため、静的攻撃に耐性がある。こうして、変換されたプログラムのファンクションコールレイアウトの解析を試みる襲撃者は、保護されるプログラムにおける関数の関数バウンダリ、コールサイトおよび実行の順序が、コンパイラ／リンカにより変更されるために、見せかけのレイアウトを入手することになる。変換されたプログラムがコンピュータ９０４によって実行されると、変換されたプログラムの実行とともにファンクションコール構造が自己修正を行い、それにより関数が呼び出される時期と方法を変更することで元のファンクションコールグラフを変更する。

実施例において、関数バウンダリの修正を行うコードは、プログラムと同じ実行スレッドにある必要はない。随意には、同時実行のスレッドまたはプログラムコードとオペレーティングシステム（ＯＳ）との間にあるヴァーチャルマシン層に置くことができる。したがって、修正コードはプログラムとは独立しており、プログラムの機能性と関連付けてまたは切り離して実行することができる。代替的には、関連付けおよび分離のアプローチを組み合わせることもできる。

図１０ａから図１０ｃは、発明の実施例による動的ファンクションコールシステムのための代替的オペレーションセットアップを示す図である。

図１０ａは、アプリケーションプログラムとオペレーティングシステム（ＯＳ）との間に置かれたアプリケーションヴァーチャルマシンを示す図である。ヴァーチャルマシンは、命令の実行を管理する。命令実行の準備ができると、ヴァーチャルマシンは、命令を翻訳するかまたは直接ＯＳへ送ってネイティブに実行させることができる。この実施例では、ヴァーチャルマシンは、実行されているアプリケーションプログラムに対する命令修正を実行する。命令修正がアプリケーション自体の内部にある場合と同様、類似する構築時解析ツールがこのセットアップのために必要である。

図１０ｂは、アプリケーションプログラムとともに実行される同時実行のプロセスまたはスレッドを示す。この別個のスレッドまたはプロセスは、アプリケーションプログラムとは準独立状態で実行される。この場合、別個のプロセスまたはスレッドは、いくつかの同期または非同期実行スキームのいずれかを介してアプリケーションプログラムと同時に実行する。アプリケーションプログラムに対する命令の修正は、この同時実行のプロセスまたはスレッドから作成することができる。命令修正がアプリケーション自体の内部にある場合と同様、類似する構築時解析ツールがこのセットアップのために必要である。

図１０ｃは、図１０ａおよび図１０ｂにおけるセットアップの組み合わせを示す。２つの同時実行のスレッドまたはプロセスが実行されている。さらに、ヴァーチャルマシンがアプリケーションレベルとＯＳレベルの間にある。各同時実行のアプリケーションスレッドまたはプロセスが他のアプリケーションスレッドまたはプロセスにおける命令を修正することができる。代替的には、アプリケーションスレッドまたはプロセスは、ヴァーチャルマシンにおける命令を修正することができる。同様に、ヴァーチャルマシンは、アプリケーションプロセス／スレッドのいずれかにおいて命令を修正することができる。さらに、このセットアップは、アプリケーションプロセス／スレッドのいずれかが独立した場合のように、自己修正することを妨げない。このヴァーチャルマシンも同様に自己修正が可能である。

上記では、本発明の実施例の完全な理解のため、説明を目的として、数々の詳細について提示した。しかしながら、発明を実施するためにこれら特定の詳細を必要としないことは、当業者には明らかであろう。他の例においては、発明を不明確にしないために、ブロック図の形式で、周知の電気的構成および回路について示した。たとえば、ここに記載された発明の実施例が、ソフトウェアルーチン、ハードウェア回路、ファームウェア、またはこれらの組み合わせのいずれとして実装されるかについての特定の詳細については記載されていない。

本発明の実施例は、機械可読媒体（コンピュータ可読媒体、プロセッサ可読媒体またはコンピュータ可読プログラムコードが内部に実現されたコンピュータ使用可能媒体とも呼ぶ）にストアされるソフトウェア製品として表現することができる。機械可読媒体は、ディスケット、コンパクトディスクリードオンリメモリ（ＣＤ−ＲＯＭ）、メモリ装置（揮発性または不揮発性）または同様の記憶機構を含む磁気、光学または電子記憶媒体を含むいずれか適切な有形の媒体が可能である。この機械可読媒体は、命令、コードシーケンス、コンフィギュレーション情報または他のデータの様々なセットを含むことが可能で、これらは実行されると、プロセッサが本発明の実施例に従う方法におけるステップを実行する。当業者は、記載の発明を実現するために必要な他の命令およびオペレーションも、機械可読媒体上にストアできることを理解するであろう。機械可読媒体から実行されるソフトウェアが、回路とインターフェースして記載のタスクを実行することができる。

発明の上記の実施例は例にすぎない。特定の実施例に対する変更、修正および変形例が、添付の請求項によってのみ規定される発明の範囲から逸脱することなく当業者により実行可能である。

Claims (26)

1. ソフトウェアプログラムを静的および動的攻撃から保護するために、プログラムの制御フロー構造を変更することによって、プログラムを元の形式からよりセキュアな形式へ変換する方法であって、
   ａ）プログラムの元のファンクションコール構造およびファンクションコールレイアウトを解析するステップと、
   ｂ）元のファンクションコールレイアウトを新しいファンクションコールレイアウトへ変換するステップと、
   ｃ）元のファンクションコール構造を、動的自己修正を実行することができる新しいファンクションコール構造へ変換するステップと、
   ｄ）変換された制御フロー構造を有するが意味的には元のプログラムと等価な変換されたプログラムを生成するステップとを含み、
   実行の際に、前記変換されたプログラムが、元のファンクションコールグラフを新しいファンクションコールグラフに変換するよう構成される、方法。
2. 動的自己修正により関数が呼び出される時期と態様が変更される、請求項１に記載の方法。
3. ステップａ）からｃ）が、構築時に行われる予備修正であり、元のファンクションコールグラフを新しいファンクションコールグラフに変換するステップが、実行時に行われて、ステップａ）からｃ）において計画された動的変更が実行される、請求項１に記載の方法。
4. ステップａ）が、プログラムを変換する時に、重要な関数を強調するため、プログラムにおける各関数の重要性のレベルを決定するステップをさらに含む、請求項１に記載の方法。
5. ステップｂ）およびｃ）が、関数バウンダリを変更して、ファンクションコールレイアウトを偽装するステップを含む、請求項１に記載の方法。
6. 関数バウンダリを変更するステップが、関数バウンダリを壊しかつ２つ以上の関数を１つに結合するステップを含む、請求項５に記載の方法。
7. 関数バウンダリを変更するステップが、新たな関数バウンダリを挿入して関数を２つ以上の関数に分けるステップを含む、請求項５に記載の方法。
8. ステップｂ）およびｃ）が、変換されたプログラムの実行の際に複数のコード経路を可能にするための関数複製を挿入するステップをさらに含む、請求項１に記載の方法。
9. ファンクションコールグラフを介する実行の経路をランダムに選択するために非決定論を使用するステップをさらに含む、請求項８に記載の方法。
10. コールグラフにおける関数の実行の順序を変更するステップをさらに含む、請求項１に記載の方法。
11. 新しい関数を創出しかつ新しいファンクションコールを挿入するステップをさらに含む、請求項１に記載の方法。
12. 戦略ポイントにデコイを挿入するステップをさらに含む、請求項１に記載の方法。
13. 命令を修正してそれらの挙動を変更するステップをさらに含む、請求項１に記載の方法。
14. 命令を削除しかつそれらをノーオペレーション（ＮＯＰ）命令と置換するステップをさらに含む、請求項１に記載の方法。
15. プログラムにダメージを行うステップをさらに含み、そのダメージが、ファンクションコール構造をさらに偽装しかつ元のプログラムに対して機能的等価性を維持するための１つ以上のフィックスアップダメージにより追随される１つ以上の改変性のダメージを含む、請求項１に記載の方法。
16. 呼び出された関数の証拠を削除するステップをさらに含む、請求項１５に記載の方法。
17. 各改変性のダメージが１を超える数のフィックスアップダメージを有する、請求項１５に記載の方法。
18. 変換されたプログラムが、実行されると常に異なるファンクションコールグラフを有するように設定するステップをさらに含む、請求項１に記載の方法。
19. ステップａ）が、プログラムを修正するためのプログラムにおける戦略ポイントを決定するステップをさらに含む、請求項１に記載の方法。
20. ステップａ）が、複雑な予備解析工程を行って、プログラムのファンクションコール構造、ファンクションコールレイアウトおよびファンクションコールグラフ全体を理解するステップを含む、請求項１９に記載の方法。
21. ステップｂ）およびｃ）が、プログラムにおける修正ポイントを、対応の実行ポイントから物理的にかつ時間的に遠いポイントに配置するステップをさらに含む、請求項１９に記載の方法。
22. 実行ポイントについて複数の修正ポイントを設けるステップをさらに含む、請求項２１に記載の方法。
23. 変換された制御フロー構造が、新しいファンクションコールレイアウトおよび新しいファンクションコール構造を含む、請求項１に記載の方法。
24. 変換された制御フロー構造が、ジャンプ、ブランチ、リターンおよび例外のうちの１つ以上をさらに含む、請求項２３に記載の方法。
25. ソフトウェアプログラムを静的および動的攻撃から保護するために、プログラムの制御フロー構造を変更することにより、プログラムを元の形式からよりセキュアな形式に変換する方法であって、前記方法が、構築時フェーズと実行時フェーズとを含み、前記構築時フェーズが、
    ａ）プログラムの元のファンクションコール構造およびファンクションコールレイアウトを解析するステップと、
    ｂ）プログラムの元のファンクションコールレイアウトを新しいファンクションコールレイアウトに変換するステップと、
    ｃ）ファンクションコール構造を動的修正を行うことができる新しいファンクションコール構造に変換するステップと、
    ｄ）変換された制御フロー構造を有するが、意味的には元のプログラムに等価な変換されたプログラムを生成するステップとを含み、
    前記実行時フェーズが、
    ｅ）プログラムの実行に際して、プログラムの元のファンクションコールグラフを新しいファンクションコールグラフに変換するステップを含み、
    実行時に行われる動的修正が、構築時に行われる変更に相補的で、元のプログラムに対して意味的に等価な変換されたプログラムを生成する、方法。
26. ソフトウェアプログラムを動的および静的攻撃から保護するため、プログラムの制御フロー構造を変更することにより、プログラムを元の形式からよりセキュアな形式に変換するためのステートメントおよび命令を記録したコンピュータ可読メモリであって、
    前記ステートメントおよび命令は、プロセッサで実行されると、プロセッサが、
    ａ）プログラムの元のファンクションコール構造およびファンクションコールレイアウトを解析するステップと、
    ｂ）元のファンクションコールレイアウトを新しいレイアウトに変換するステップと、
    ｃ）元のファンクションコール構造を、動的自己修正を行うことができる新しい構造に変換するステップと、
    ｄ）変換された制御フロー構造を有するが、元のプログラムに対して意味的に等価な変換されたプログラムを生成するステップとを実行するようになっており、前記変換されたプログラムが、実行に際して、元のファンクションコールグラフを新しいファンクションコールグラフに変換するよう構成される、メモリ。

Images