(57)【特許請求の範囲】
【請求項１】
実行可能なソフトウェアに対応するソースコードに完全性チェックを導入する場所を決定し、最終的な保護された実行可能なソフトウェアが改竄されたか否かの検証を可能にするために前記実行可能なソフトウェアの実行時プロファイリングを採用するコンピュータにより実現されたことを特徴とする改竄防止システム。
【請求項２】
前記最終的な保護された実行可能なソフトウェアに対する性能影響を最小限にするために完全性チェックを導入する場所を決定するように動作可能であることを特徴とする請求項１記載のシステム。
【請求項３】
前記最終的な保護された実行可能なソフトウェアの改竄に対する保護を最大にするために完全性チェックを導入する場所を決定するように動作可能であることを特徴とする請求項１又は２記載のシステム。
【請求項４】
各チェックが行うべき作業量を判定するように動作可能であることを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
【請求項５】
（ａ）  元の保護されていない実行可能なソフトウェアは、前記実行可能なソフトウェアに関するタイミング及び／又は構造情報を提供するために実行時にプロファイルされ、
（ｂ）  この情報は、挿入される前記チェックに関して決定を行うために処理され、
（ｃ）  前記チェックは、ハッカーによる改竄に対して耐性のある最終的な保護されたバージョンを生成するために、前記実行可能なソフトウェアに対応するソースコードに挿入されることを特徴とする請求項１乃至４のいずれか１項に記載のシステム。
【請求項６】
前記実行可能なソフトウェアの前記プロファイリングの目的は、前記ソフトウェアの種々の構成要素のレイアウト、構造及びタイミングのうちの１つ以上に関するデータを収集することであることを特徴とする請求項５記載のシステム。
【請求項７】
実行可能なプログラムの性能及び改竄に対する保護への影響に関して戦略的な決定を自動的に行うように設計された導入ポリシーを使用することを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
【請求項８】
（ａ）  機能実行回数、実行時間及び実行可能なプログラムの合計の実行時間である基本的なプロファイリング情報；
（ｂ）  あらゆる所定の機能により呼び出される機能及び呼び出される頻度を記録するコールグラフ；
（ｃ）  各機能が呼び出される際の頻度及び各頻度が発生する時間帯を記録する頻度領域のタイミング；
（ｄ）  あらゆる所定の機能の前に実行された機能を記録する実行グラフ
の集合から選択された１つ以上の記録の種類を使用することを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
【請求項９】
頻度領域情報は、
ａ．低頻度機能が性能オーバヘッドを最小限にするのに適切な候補であること；
ｂ．高頻度機能が実行されているチェックのレベルを最大にするのに適切な候補であること；
ｃ．低頻度機能と高頻度機能との間の妥協により、低い性能オーバヘッドと強力な保護との間の実質的な均衡が可能になること；
ｄ．ある期間にわたりあらゆる所定の機能の頻度範囲を考慮することにより、異常な頻度の挙動が回避されるか又は補償され、
i. 性能オーバヘッドを考慮する場合、機能毎に発生する最大の頻度を使用し（頻度が非常に短い期間発生する場合以外）、
ii. チェックレベルを考慮する場合、機能毎に発生する平均頻度又は中間頻度を使用すること
のうち１つ以上の規則を適用することにより、最適な導入ポイントを判定するために使用されることを特徴とする請求項８記載のシステム。
【請求項１０】
前記コールグラフ及び実行グラフ情報は、
ｅ．各ゾーンが複数の他の機能によりチェックされ、理想的には、前記ゾーンのコードの直前に実行する機能に少なくとも１つのそのようなチェックを配置し、前記ゾーンの前記コードの直後に実行する機能に１つのチェックを配置すること；
ｆ．コールグラフの親機能は、前記親機能が呼び出すあらゆる機能に対して機能の前後に有効であると考えられること
のうち１つ以上の規則を適用することにより自己検査トポロジを誘導するために使用されることを特徴とする請求項８記載のシステム。
【請求項１１】
コールグラフの記録には、静的テーブル及び入力された機能のスタックが使用されることを特徴とする請求項８記載のシステム。
【請求項１２】
前記静的テーブルは、機能及び呼び出す（親）機能により索引付けされた２Ｄテーブルであり、前記親機能の索引は現在のスタックの最上部から取得され、前記テーブルは、親−子の対毎のエントリ数を記録し、前記コールグラフ全体は、テーブルの親−子のパスに従って統計的に再構成されることを特徴とする請求項１１記載のシステム。
【請求項１３】
前記頻度領域の記録には、機能及び頻度により索引付けされた２Ｄテーブルである静的テーブルが使用され、前記テーブルは、機能毎にプログラムにおける頻度の発生の開始時間及び終了時間を保持し、頻度索引は、精度とテーブルのサイズとの間の妥協点を提供するためにlog2であり、テーブルの問い合わせは、境界の場合の処理を簡略化するために隣接する頻度スロットを合わせ、機能の呼び出し頻度は２つのスロットにわたることを特徴とする請求項８記載のシステム。
【請求項１４】
実行グラフの記録には、現在の機能及び先行機能により索引付けされた２Ｄテーブルである静的テーブルが使用され、前記先行機能は、単一の値として格納され、前記テーブルは、先行機能−現在の機能の対毎にエントリ数を記録し、前記実行グラフ全体は、テーブルの先行機能−現在の機能のパスに従って統計的に再構成されることを特徴とする請求項８記載のシステム。
【請求項１５】
特に非同期通信及び／又はハードウェアが含まれる場合に、正確なタイミング情報を得ることにより、実行可能なプログラムの性能に対する影響を最小限にするように設計されたプロファイラを更に含むことを特徴とする請求項１乃至１４のいずれか１項に記載のシステム。
【請求項１６】
ソース解析により機能が列挙されることを特徴とする請求項１乃至１５のいずれか１項に記載のシステム。
【請求項１７】
プロファイリングテーブルが事前に割り当てられることにより、性能影響を最小限にし、各プロファイルポイントが直接テーブルアクセスを使用することにより、更に性能影響を最小限にすることを特徴とする請求項１６記載のシステム。
【請求項１８】
最終的な保護された実行可能なソフトウェアの完全性をチェックできるように前記実行可能なソフトウェアに対応するソースコードを変更する、コンピュータにより実現された改竄防止システムによって実行される方法であって、該改竄防止システムの実行時プロファイリング手段が、（ｉ）完全性チェックを前記実行可能なソフトウェアに対応するソースコードに導入する場所を決定するために前記実行可能なソフトウェアに対して実行時プロファイリングを行うステップと、（ｉｉ）該改竄防止システムの導入手段が、前記実行可能なソフトウェアに対応するソースコードに対して前記完全性チェックを導入するステップと、を有することを特徴とする方法。
【請求項１９】
請求項１乃至１７のいずれか１項に記載のシステムにより実行されたあらゆる更なるステップを更に含むことを特徴とする請求項１８記載の方法。
【請求項２０】
コンピュータ可読媒体に格納されたコンピュータプログラムであって、請求項１乃至１７のいずれか１項に記載のシステム、あるいは請求項１８又は１９記載の方法を使用して導入された完全性チェックを含むことを特徴とするコンピュータプログラム。
【請求項２１】
コンピュータ可読媒体に格納されたコンピュータプログラムであって、（i）実行可能なソフトウェアに対応するソースコードに完全性チェックを導入する場所を決定するために前記実行可能なソフトウェアの実行時プロファイリングを採用し、（ii）前記完全性チェックを前記実行可能なソフトウェアに対応するソースコードに導入するように動作可能なコンピュータプログラム。
【請求項２２】
請求項１乃至１７のいずれか１項に記載のシステムにおいて使用されるか、あるいは請求項１８又は１９記載の方法を実行するために使用されることを特徴とする請求項２１記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改竄防止システム、すなわちハッカーがソフトウェアを変更することを困難にするシステムに関する。システムは、ユーザによる設定又は介入が殆どない高性能でセキュリティの高いシステムを達成するために固有の自動解析を採用する。
【背景技術】
【０００２】
現代の生活において、コンピュータソフトウェアアプリケーションは広く普及している。コンピュータソフトウェアアプリケーションを使用するユーザは楽しみ満足し、それらがないと出来ないことを可能にする複雑な手順が自動化される。コンピュータソフトウェアアプリケーションは、通信を可能にし、複雑な情報を提供且つ視覚化するのを支援できる。これらの全ての能力において、好適なソフトウェアは、消費者が代金を支払う価値のある商品である。
【０００３】
その結果、急成長するソフトウェア業界は、この市場の需要を満たすような製品の開発に巨額の投資をしてきたし、投資し続けている。
【０００４】
この資産を保護するために、開発者及び発行者は、ソフトウェアに保護を挿入し、許可された人のみがそのソフトウェアを使用でき且つ他の人が秘密を得るためにそのソフトウェアを解析したり又はソフトウェアの挙動を変更するためにソフトウェアを変更したりすることにより優位に立つことはできないことを保証する。
【０００５】
しかし、リバースエンジニアリング及びそのようなソフトウェアの変更に熟練した個人（ハッカー）が多く存在する。彼らの目的は、例えば「トライアル」の制限を除去し、秘密の暗号情報にアクセスし且つオンライン競争で不正行為をするために、挿入された保護を回避することである。「ハッキング」されたバージョンは、通常インターネット上で潜在的に数千人ものユーザに配布され、ソフトウェア会社の収益に明らかに影響を及ぼす。
【０００６】
「改竄防止」システムの目的は、ハッカーが保護された市販のソフトウェアを変更することを防止するか又は少なくとも非常に困難にすることである。
【０００７】
改竄防止システムにより採用された方法は、大きく２つの主な分野に入る。
【０００８】
第１に、コードを難読化する。ソフトウェアを変更する前の分かりやすい原型は、動作方法、場合によっては限られた範囲内での動作方法を理解する。この理解する処理を困難にするためにアプリケーションコードを難読化するための方法が多くの特許で説明されている。尚、難読化されたコードは、難読化された状態で実行されてもよく、あるいはコード暗号化が使用される場合のように実行される前に難読化解除が行われる必要があってもよいことが重要である。いずれの場合においても、ハッカーが難読化処理を理解できた場合、保護が無効にされるという問題がある。ハッカーが有する困難さ及び保護システムの強度を判定することは容易ではない。
【０００９】
本発明において使用される第２の方法は、アプリケーションが改竄されていないことを検証することである。ここで、改竄には、コード及び／又はデータの変更、実行環境に対する変更、あるいは最終的にアプリケーションの挙動を変更する他のあらゆる方法が含まれる。これらの検証ポイントを「完全性チェック」と呼ぶ。
【００１０】
例えば正常に実行している間、アプリケーションは自身のコードの完全性をチェックしてもよい。アプリケーションコードの特定の領域は、コードの別の（対象）領域が変更されていないことを検証するためにチェックサムアルゴリズムを使用してもよい。そのようなチェック方法の推定により、相互チェック網（トポロジ）が構成される。アプリケーションコードに対するあらゆる変更が検出され、防御対策が行なわれることを意図する。これらのコード完全性チェックは、既存のプログラムに手作業で又は自動的に導入される。
【００１１】
Chris Crawfordは、論文を公開し、自己検査システムにハッキングを防止する機能を与えるためにチェックサムを使用することを説明した。Crawfordは、これより前にPatton Strikes Backを保護するために１９９０年にこのシステムを採用し、１９８８年にTrust and Betrayalを保護するために使用していた可能性がある。原物の論文を見つけるのは困難であるが、Crawfordは２００３年の自身の著「Chris Crawford on Game Design」においてPatton Strikes Backで使用された自己検査システムを説明しており、それ以来全ての自己検査保護システムにより使用されている基礎的な概念である大きな「チェック網」を形成するために互いに検査する検査について明示している。更にCrawfordは、検査及びあらゆる応答を隠すために分散を使用することを説明している。
【００１２】
この基本的な方法の多くの種々の変形例が公開されている。
【００１３】
完全性チェックの別の形態は、デバッギング／ハッキングツールの存在を明らかにできるか又はハッカーが保護されたプログラムに対してそのようなツールを容易に配布できないようにそれらを使用不能にする技術を使用することを含む。この種の完全性チェックは、一般にアンチデバッグ手法と呼ばれる。これは、既存のプログラムに手作業で又は自動的に導入される。
【００１４】
そのような方法においては大きな問題があり、その問題に対しては新しい枠組み及び技術を導入することにより本発明の方法を使用して対処する。
【００１５】
完全性チェックが実行時に実行されているため、保護アプリケーションに対する性能が犠牲になる可能性がある。チェックが不適切な時に実行されると、ユーザ体験は低品質なものになる可能性がある。この危険性を最小限にするために、開発者は、少ない数のそのようなチェックを加える傾向がある。その結果、保護強度は低下する。すなわち、ハッカーは全てのチェックを発見し易く、理解し易く且つ除去し易い。更にこれまでに考案されたコード自己検査方法は、チェックされたコードが実行される時期と比較していつチェックが実行されるかという問題に対処していない。偶然に任せると、ハッカーは非常に容易に自身が望むコードを変更し、それを実行し且つそれを元の状態に戻せるだろう。
【００１６】
従って、特にユーザの介入が殆ど必要とされない場合、多くのチェック、実行時性能及び結果として得られる保護強度の関連する側面を均衡させることは、完全性検証保護方式を正常に適用するための鍵である。更に、その方式がアプリケーションコード実行の実行時シーケンスを考慮に入れることが重要である。
【発明の概要】
【００１７】
本発明は、ソフトウェアが改竄されたか否かの検証を可能にするために完全性チェックをソフトウェアに導入する場所を決定するために、ソフトウェアの実行時プロファイリングを採用するコンピュータにより実現された改竄防止システムを提供する。更に、各チェックが行うべき作業量が決定されてもよい。種々のチェックを配置する場所は、各チェックが行うべき作業量及び所定の場所に配布されたチェックの種類に基づいてもよい。
【００１８】
一実現例において、性能の犠牲及び手作業による設定の必要性を最小限にしつつ、保護セキュリティを最適化するために実行時完全性チェックの場所、対象及び可能な労力を設定するために、実行時プロファイリング及び解析を使用してアプリケーションに関する情報を記録する方法が存在する。更なる一実現例において、本発明は、プロファイリング及び情報収集、並びにこの情報の使用の方法を提供し、実際のアプリケーションにおいて本発明の有効性を向上する。
【００１９】
本発明の他の態様は以下を含む。
【００２０】
・ソフトウェアの完全性をチェックすることを可能にするようにソフトウェアを変更する方法であり、ソフトウェアに完全性チェックを導入する場所を決定するためにソフトウェアに対して実時間プロファイリングを行うステップを有することを特徴とする方法。
【００２１】
・コンピュータ可読媒体に格納されたコンピュータプログラムであり、上述したシステム又は方法を使用して導入された完全性チェックを含むことを特徴とするコンピュータプログラム。
【００２２】
・コンピュータ可読媒体に格納されたコンピュータプログラムであり、ソフトウェアに完全性チェックを導入する場所を決定するためにソフトウェアの実行時プロファイリングを採用するように動作可能なコンピュータプログラム。
【図面の簡単な説明】
【００２３】
【図１】図１は、本発明を概略的に示す図である。
【発明を実施するための形態】
【００２４】
実行時に完全性チェックを実行する改竄防止方式において、本発明は、チェックコードの挿入を自動化し、コードの場所に対する最適化された位置を判定し、チェックされるアプリケーションメモリの領域をより適切に決定し、各チェックが行うべき作業量を判定し、且つチェック処理において種々の他の設定可能なパラメータを最適化する方法を説明する。
【００２５】
本発明は３段階から成る処理である。
【００２６】
・第１に、元の保護されていないアプリケーションは、実行時にプロファイルされ、アプリケーションに関するタイミング及び／又は構造情報を提供する。プログラムは、インストルメント又は変更されずにあらゆる方法でプロファイルされる。例えばサンプリングを用いたプロファイラが使用可能である。インストルメントも可能である。詳細な情報、又は構造情報を含むような情報、を記録することにより更に適切な結果を提供できるが、記録された情報は、そのような情報である必要はない。
【００２７】
・第２に、この情報は挿入されるべきチェックに関する決定を行うために処理される。
【００２８】
・第３に、ハッカーによる改竄に対する耐性がある最終的な保護されたバージョンを生成するために、チェックはアプリケーションに挿入される。
【００２９】
これを図１に概略的に示す。好適な実施形態は、保護されるアプリケーションに対するソースコードを処理する。本実施形態において、第１の段階におけるプロファイリングは、アプリケーションソースコードに対する変更を自動的にインストルメントし且つ標準的な方法でコードをコンパイルすることにより実現される。データは、インストルメントされたアプリケーションを実行することにより収集される。同様に、第３の段階では、必要なチェックを導入するためにアプリケーションソースコードを再度変更し、保護されたアプリケーション自体は標準的な技術を使用してコードをコンパイルした結果として得られる。
【００３０】
従来技術を体験し且つ従来技術に精通しているユーザは、アプリケーションコードのアセンブリ言語のバージョンが変更される場合、あるいはアプリケーションのオブジェクトコード自体が変更される場合、あるいはプロファイリング要素の場合にはいかなるコードも変更されない場合等の本発明の更なる応用例をすぐに認識できるが、それらに限定されない。
【００３１】
上記の第１の段階におけるプロファイリング及びその後の対象アプリケーションの実行の目的は、種々の構成要素のレイアウト、構造及びタイミングに関するデータを収集することである。尚、上述したように、それらの全てが基本動作に必要なわけではない。
【００３２】
好適な実施形態において、このデータを取り込むためにアプリケーションをインストルメントする処理に対する鍵は、アプリケーションの機能が列挙されるプレインストルメンテーション静的解析である。これは、プロファイリングテーブルが静的に割り当てられ、実行時に全てのデータが直接テーブルアクセスにより更新されることを意味する。これにより、収集したデータに影響を及ぼさないように、対象アプリケーションに対する性能影響は低減される。
【００３３】
方法は、いくつかの種類の情報を収集する。
【００３４】
・機能実行回数、実行時間及び合計のプログラム実行時間等の基本的なプロファイリング情報。
【００３５】
・コールグラフデータは、どのアプリケーション機能が他のどのアプリケーション機能により呼び出されるかを取り込む。これは、この呼び出し処理が行われた回数、行われた時期、並びに各機能自体の実行時間及び自身が呼び出す機能の実行時間を含む各機能の実行時間を記録する。これにより、完全なアプリケーションコールグラフが再構成可能である。
【００３６】
・実行グラフデータは、機能の実行順序を取り込む。これは、対象をチェックに割り当てるための重要な情報を提供する。
【００３７】
・頻度領域データは、所定のあらゆる機能が呼び出される際の時間頻度及びアプリケーションの実行時に各頻度が発生する時期を取り込む。例えばプログラムの実行の一部分において、特定の機能が非常に頻繁に何回も呼び出されてもよい。そのアプリケーションの存続期間の後半で、再度呼び出されることがなくてもよい。そのような情報は、効率的でセキュリティ保護されたチェック網を確立するのに不可欠であり、一般に汎用プロファイラアプリケーションにより取り込まれない。
【００３８】
これらの情報が組み合わされることにより、性能影響が最小である可能性があり且つ強度が最高である可能性がある位置にチェックを配置できる。更にシステムは、ソフトウェア開発者にとって使用し易く、専門的なセキュリティ知識を必要としない。
【００３９】
例えばアプリケーションの１分間の実行時に２，０００回呼び出される機能は、ほぼ１／３０秒に１回呼び出されるため中頻度機能と解釈され、チェックを導入するのに適切な場所である。
【００４０】
しかし、この特定の機能はアプリケーションの開始後最初の１秒間に２，０００回呼び出されたが、その後は再度呼び出されることがないような機能であってもよく、これにより一時的な高頻度機能になる。
【００４１】
この機能又は同様の機能にチェックを導入することは、アプリケーションの起動時に大きく影響を及ぼし、望ましくない。同様に、不完全な情報に基づいてアプリケーションの時間の影響を受け易い対話型の部分にチェックを導入することにより、アプリケーションのユーザにとって非常に顕著である性能のスパイクが起こる可能性がある。
【００４２】
これを解決するために、本発明の導入システムは、機能が実際には一時的な高頻度機能であることを判定するために記録する頻度領域情報を使用し、それに従って動作する。
【００４３】
更に、本発明の導入システムは、あらゆる所定の機能の時間的安定性に関して信頼度計測値を設定するためにこの頻度領域情報を使用する。機能がプロファイリング中に多くの種々の頻度で実行すると考えられる場合、その機能は時間的に不安定であると考えられ、アプリケーションの将来の実行時に他の未知の（可能性として非常に高い）頻度で実行する可能性が高いと仮定する。従って、この機能は性能のスパイク又は単純に全体的に低い性能をもたらす可能性があるため、不適切な導入対象になる。一般にそのような機能への導入を回避する一方で、より安定した別の機能が利用可能である。
【００４４】
性能を低下させる導入、すなわちスパイクを導入する導入の可能性が非常に低減されるため、当然、この機構は安全に導入できるチェック数を増加する。そのような機構がない場合、一般にユーザは不適切な導入を回避するためにチェック数を「戻す」必要があり、最終的には導入できるチェック数を制限する必要がある。これにより、適用された保護の強度は数桁も厳しく制限される。
【００４５】
本発明の導入システムは、主に性能の観点から、あらゆる所定のチェックがとるべき形態を決定するためにプロファイリングデータを更に使用する。より高価なチェックは、呼び出される頻度がより少ない機能に導入される傾向があり、より安価なチェックは、呼び出される頻度がより多い機能に導入される傾向がある。一般に、チェックが導入される機能と関連付けられたプロファイルデータとチェックの性能特性とを密接に関係付けることにより、関係付けない場合より大きい性能影響を与えることなく、より多くのチェックをアプリケーションに導入できる。尚、保護されたアプリケーションの性能プロファイルを見ているハッカーにより導出される可能性のある導入の決定を改竄防止システムが行うことは望ましくないため、この関係付けは故意に不完全である場合が多い。
【００４６】
コード自己検査の場合、チェックのコストは、他の特性（アクセスされるメモリの種類及び速度等）も状況によっては重要であるが主にチェックされるコード量及びチェックを実行するのに使用されるチェックサムアルゴリズム（又は他の完全性チェックアルゴリズム）に依存する。
【００４７】
尚、本発明のシステムは、性能に大きく影響を及ぼさずに配布できるチェック数を更に増加するためにより頻繁に呼び出される機能において使用される増分チェック及び定期的なチェック等のコード自己検査に対してコストを削減する方法を採用できる。
【００４８】
アンチデバッグチェックの場合、一般にチェックのコストは、導入されるアンチデバッグ技術毎に固有である。一部のアンチデバッグチェックは、オペレーティングシステム又はＣＰＵにおいて非常に高価な例外機構をトリガすることを含んでもよいが、他のアンチデバッグチェックは、少数の安価な動作のみを含んでもよい。
【００４９】
他の形態の完全性チェックは同様に処理される。ここで、各チェックは実行時コストに関して評価され、一般にこのコストはアプリケーションに対するプロファイルデータと密接に関係付けられる。
【００５０】
主に本発明は、あらゆる所定のレベルの性能影響に対してチェック数及びチェックが行うチェック作業量を最大にすることにより向上した保護強度を提供する。一般にチェック数が多い程（且つチェック活動が多い程）、ハッカーは保護を無力化するためにより多くの作業を行う必要があることを意味し、これは実世界の保護強度の有用な尺度である。
【００５１】
本発明は、他の手段により向上された保護を更に提供する。他の手段には、一般にコードが実行される直前及び実行された直後にチェックされることを保証すること、一般に相互依存するチェックがアプリケーションの実行プロファイルにおいて互いに近接して実行されることを保証すること、並びに一般に同一の対象、種類又はモードの動作に対する複数のチェックが時間、空間及び頻度において標準的なランダム分布で分離されることを保証することが含まれるが、これらに限定されない。これらの目標の相反する特性のために、全ての目標が適切な範囲で満たされるように、各目標の重要性がチェック間で分散される。
【００５２】
これらの保護強度を向上する目的は、保護されているアプリケーションに対して記録するコールグラフ、実行グラフ及び頻度領域プロファイリング情報を使用することにより達成可能である。例えば、コールグラフ及び実行グラフにより、一般にアプリケーションの機能が互いに対していつ実行されるかを判定できるため、コードが実行の前後にチェックされることを保証できる。同様に、一般に相互依存するチェックが同一のコールグラフ及び実行グラフデータを使用して又は頻度領域データを使用して時間的に互いに近接して実行されることを保証でき、これにより、各機能が各呼び出し頻度で実行する時期に関する大まかな指示が提供される。この同一のデータは、時間及び空間において同一の対象、種類又はモードの動作によりチェックの分散を最大にするために使用される。
【００５３】
コードを実行の前後にチェックすることにより、自己検査機構が一時的な変更を検出しないように、ハッカーがコードを変更し、それを実行させ且つ元のコードを置換する機会の可能性を可能な限り短い時間に低減し、どの所定の時点においても自己検査システムの効果を最大限にする。
【００５４】
相互依存するチェックが一般に時間的に互いに近接して実行するようにそれらのチェックを配置することにより、コードの他の有効なセクションとは相対的に関係なく実行されるコードの有効なセクションを含むアプリケーションは、一般にチェックを含むコードとは非常に異なる時間に実行されるコードを範囲に含むチェックが多すぎるために低減された保護強度の悪影響を受けないことを保証する。
【００５５】
時間及び空間において同一の対象、種類又はモードの動作によりチェックを分散することにより、一般に、ハッカーが保護方式のパターンを見つけ且つ利用するのに更に労力を必要とすることを保証する。この目的は、上述の２つの目的が単独で動作可能な場合に低品質な分散を結果として与える可能性があるため、それらの目的を強化するために更に使用される。
【００５６】
本発明の一実現例において、貪欲算法を使用して説明された最適化する目的の全てを組み合わせる。ここで、チェックの配置、チェックの形態、チェックの対象（該当する場合）及びチェックにより行われる作業量に対する最適な決定は、性能及び保護強度を最大にすることに関連して説明した全ての目的及び構築されたチェックトポロジに対して各段階で行われる。本発明の別の実現例において、別の最適化処理が使用されてもよい。別の最適化処理には、全ての可能なチェックトポロジの総当り検索又は本明細書で設定された目的に従って最適な適合性を有するチェックトポロジを判定するために遺伝的アルゴリズムを使用することが含まれるが、これらに限定されない。
【００５７】
ソフトウェアツールである本発明の一実現例において、ソフトウェアは以下のように使用される。
【００５８】
１．ソフトウェアは、他のソフトウェアアプリケーションを開発するために使用されるコンピュータシステムにインストールされる。
【００５９】
２．コンパイルされる全てのソースファイルが本来のコンパイラに渡される前にソフトウェアを通過し且つプロファイリングインストルメンテーション又は保護コードを導入するためにソフトウェアにより変換されるように、また、コンパイル後の最終的なプログラムが発生した際にソフトウェアが動作可能であるように、ソフトウェアはコンパイル処理を中断するために手作業で又は自動的にセットアップされる。
【００６０】
３．保護されているアプリケーションは、全てのソースファイルがソフトウェアを通過するようにコンパイルされ、ソフトウェアは「解析モード」に設定され、プロファイリングインストルメンテーションをアプリケーションに導入する。
【００６１】
４．その後保護コードが導入される時に効果的な決定を行うのに必要とされる情報をプロファイリングインストルメンテーションが実行時に収集できるように、インストルメントされたアプリケーションが実行される。
【００６２】
５．実行中、プロファイリングインストルメンテーションに対して可能な限り多くのアプリケーションコードが実行されるように、アプリケーションは、ユーザにより又は自動化されたテストを使用して「実行」される。
【００６３】
６．アプリケーションは、ソフトウェアが保護コードをアプリケーションに導入する「保護モード」に設定された状態で再度コンパイルされ、前の段階で収集されたプロファイリングデータに従って決定を行う。各保護コードの特性及び場所は、次の段階で使用するために記録される。
【００６４】
７．コンパイル後、ソースコードレベルで又はコンパイル中に行えないある特定の保護の側面を解決するために、ソフトウェアは前の段階の記録された保護情報を使用して最終的なプログラムバイナリを変更する。例えば、コードのチェックサムは、最終的なコードで計算される必要があるため、これはバイナリ自体に対する最終的な処理として行われる。
【００６５】
８．結果として得られるプログラムバイナリが保護される。
【００６６】
本発明の実現例の主な特徴の概要は以下の通りである。
【００６７】
以下の２つの主な目的のために使用されるプロファイリングシステム。
【００６８】
・基礎となるプログラムに対する性能影響を最小限にするために、完全性チェックを導入する場所及び各チェックが行うべき作業量を決定すること。
【００６９】
・改竄に対する保護を最大にするために完全性チェックを導入する場所を決定すること。
【００７０】
プログラム性能に対する影響を最小限にするように設計されたプロファイラが使用されてもよい。これは、特に非同期通信及び／又はハードウェアが含まれる場合に、正確なタイミング情報を得るために重要だろう。
【００７１】
導入ポリシーは、プログラム性能及び改竄に対する保護への影響に関して戦略的な決定を自動的に行うように設計される。すなわち、ソフトウェア開発者の介入又は専門的なセキュリティ知識を必要とせずに保護を容易に使用し且つ適用できるように設計される。
【００７２】
ソース解析により、機能が列挙される。
【００７３】
・プロファイリングテーブルが事前に割り当てられることを可能にし、性能影響を最小限にする。
【００７４】
・各プロファイルポイントは直接テーブルアクセスを使用し、性能影響を更に最小限にする。
【００７５】
システムはいくつかの記録の種類を使用してもよい。
【００７６】
・機能実行回数、実行時間及び合計のプログラム実行時間等の基本的なプロファイリング情報。
【００７７】
・コールグラフ−あらゆる所定の機能により呼び出される機能及び呼び出される頻度を記録する。
【００７８】
・頻度領域のタイミング−各機能が呼び出される際の頻度及び各頻度が発生する時間帯を記録する。
【００７９】
・実行グラフ−あらゆる所定の機能の前に実行された機能を記録する。
【００８０】
コールグラフの記録には、静的テーブル及び入力された機能のスタックが使用されてもよい。
【００８１】
・静的テーブルは、機能及び呼び出す（親）機能により索引付けされた２Ｄテーブルである。親機能の索引は現在のスタックの最上部から取得される。
【００８２】
・テーブルは、親−子の対毎のエントリ数を記録する。
【００８３】
・コールグラフ全体は、テーブルの親−子のパスに従って統計的に再構成される。
【００８４】
・この方式により、情報の内容と記録するコストとの間の最適な妥協点が得られる。
【００８５】
頻度領域の記録には、静的テーブルが使用されてもよい。
【００８６】
・静的テーブルは、機能及び頻度により索引付けされた２Ｄテーブルである。
【００８７】
・テーブルは、機能毎にプログラムにおける頻度の発生の開始時間及び終了時間を保持する。
【００８８】
・頻度索引は、精度とテーブルのサイズとの間の妥協点を提供するためにlog2である。
【００８９】
・テーブルの問い合わせは、境界の場合の処理を簡略化するために隣接する頻度スロットを合わせる。ここで、機能の呼び出し頻度は２つのスロットにわたる。
【００９０】
実行グラフの記録には、静的テーブルが使用されてもよい。
【００９１】
・コールグラフの記録と同様に、現在の機能及び先行機能により索引付けされた２Ｄテーブルである。先行機能は、単一の値（コールグラフの場合のようなスタックではなく）として格納される。
【００９２】
・テーブルは、先行機能−現在の機能の対毎にエントリ数を記録する。
【００９３】
・実行グラフ全体は、テーブルの先行機能−現在の機能のパスに従って統計的に再構成される。
【００９４】
・この方式により、情報の内容と記録するコストとの間の最適な妥協点が得られる。
【００９５】
頻度領域情報は、自己検査コードに対する最適な導入ポイントを判定するために使用されてもよい。
【００９６】
・低頻度機能は、性能オーバヘッドを最小限にするのに適切な候補である。
【００９７】
・高頻度機能は、実行されているチェックのレベルを最大にするのに適切な候補である。
【００９８】
・低頻度機能と高頻度機能との間の妥協により、低い性能オーバヘッドと強力な保護との間の実質的な均衡が可能になる。
【００９９】
・ある期間にわたりあらゆる所定の機能の頻度範囲を考慮することにより、異常な頻度の挙動が回避されるか又は補償される。
【０１００】
・性能オーバヘッドを考慮する場合、機能毎に発生する最大の頻度を使用する（頻度が非常に短い期間発生する場合以外）
・チェックレベルを考慮する場合、機能毎に発生する平均頻度又は中間頻度を使用する。
【０１０１】
コールグラフ及び実行グラフ情報は、自己検査トポロジを誘導するために使用されてもよい。
【０１０２】
・各ゾーンは、複数の他の機能によりチェックされる。理想的には、ゾーンのコードの直前に実行する機能に少なくとも１つのそのようなチェックを配置し、ゾーンのコードの直後に実行する機能に１つのチェックを配置する。
【０１０３】
・コールグラフの親機能は、親機能が呼び出すあらゆる機能に対して機能の前後に有効であると考えられる。
【０１０４】
完全性チェックをソフトウェアに導入する場所を決定するためにソフトウェアの実行時プロファイリングを説明したが、プロファイリングソフトウェアの原理はどんな形態のプログラム変換導入を誘導するのにも使用可能である。従って、改竄防止保護コードの導入は、コードを既存のアプリケーションに導入する一例にすぎない。そのような導入に依存する他のシステムは、この方法を使用することにより低減される性能影響を有する。従って、本発明は、プロファイリングソフトウェアに拡張され、どんな形態のプログラム変換導入も誘導できる。
【図１】
0005564034.tif 000002