JP2016197399A - オペレーティング・システム・リソースに対する機械語のネイティブイメージのアクセス制御のシステム及び方法 - Google Patents

Abstract

【課題】機器のオペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセスを制御する。
【解決手段】ハードウェアプロセッサによって、機械語のネイティブイメージを取得する工程と、ネイティブイメージが生成された親アセンブリを識別する工程と、親アセンブリの信頼カテゴリーを決定する工程と、親アセンブリの信頼カテゴリーに基づいて、ネイティブイメージの信頼カテゴリーを決定する工程により、信頼カテゴリーが未信頼であるネイティブイメージのアクセスを機器のオペレーティング・システムのリソースに制限する。
【選択図】図４

Description

関連出願の相互参照。
本出願は、米国特許法第１１９条（ａ）〜（ｄ）（３５ＵＳＣ １１９（ａ）−（ｄ））下の優先権の利益を主張する。２０１５年３月３１日に出願されたロシア特許出願２０１５１１１４２２号は、本明細書中に参照として援用されるものとする。

本開示は、コンピュータサイエンスの分野に関し、特に、コンピュータ装置のオペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセス制御のためのシステム及び方法に関する。

現在、ユーザー機器（例えば、パーソナル・コンピュータ、スマートフォン、タブレットなど）にインストールできるソフトウェア・アプリケーションの数はかなり増大しており、これらのアプリケーションによって生成されるファイルの数も指数的に増えている。アプリケーションのインストールと操作において、ソフトウェア・アプリケーションにより生成される一定のファイルは、ユニーク（Ｕｎｉｑｕｅ）である。すなわち、ファイルが単一のコピーとして存在している。そのようなファイルを内容の詳細な分析をせずに分類することは、非常に難しいといえる。

しばしば、これらのファイルは、機械語の親アセンブリのイメージ（すなわち、ネイティブイメージ）であり、これは．ＮＥＴテクノロジーの一部である。．ＮＥＴアプリケーションは、いくつかのアセンブリを一緒に使って生成でき、アセンブリは、共通語ランタイム（ＣＬＲ：Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）環境によって実行されるバイナリ・ファイルである。．ＮＥＴアセンブリは以下のメタデータ要素を含む：

・ポータブル実行（ＰＥ：Ｐｏｒｔａｂｌｅ Ｅｘｅｃｕｔｉｏｎ）ファイルヘッダ；
・ＣＬＲヘッダ；
・共通中間言語（ＣＩＬ：Ｃｏｍｍｏｎ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｌａｎｇｕａｇｅ）コード；
・アセンブリのタイプ（例えば、クラス、インタフェース、構造体、列挙型、委譲型）に使用されるメタデータ；
・アセンブリのマニフェスト
・追加のビルトインリソース

一般的に、ＰＥヘッダは、ウィンドウズ（登録商標）系のオペレーティング・システムにおいてロードされ且つ実行されるアセンブリを識別する。ＰＥヘッダは、アプリケーションのタイプ（例えば、コンソールアプリケーション、グラフィック・ユーザ・インタフェース、コードライブラリなどを使用したアプリケーション）も識別する。

ＣＬＲヘッダは、すべての．ＮＥＴアセンブリをサポートできるデータにより構成され、これによりＣＬＲ環境に維持できる。ＣＬＲヘッダは、フラグ、ＣＬＲバージョン、エントリポイントのようなデータ（例えば、ｍａｉｎ（）関数の最初のアドレス）を含んでおり、これにより、実行環境が管理中のファイル（すなわちマネージコードを含むファイル）の構成を決定できる。

個々のアセンブリはＣＩＬコードを含んでおり、これはプロセッサに依存しない中間コードである。ＣＩＬコードは、実行中にリアルタイムモードで特定のプロセッサの要求に対応する指示を与える動的（ＪＩＴ：Ｊｕｓｔ Ｉｎ Ｔｉｍｅ）コンパイラによりコンパイルされる。

所要のどのようなアセンブリにも、アセンブリが参照をする外部のタイプ（すなわち、他のアセンブリにおいて示されるタイプ）だけではなく、アセンブリ内のタイプフォーマット（例えば、クラス、インタフェース、構造体、列挙型、委譲型など）を示すメタデータがある。実行環境において、メタデータは、メモリ上でのタイプの配置のためにバイナリファイルのタイプの場所を決定し、タイプメソッドのためにリモート呼び出しの処理を簡素化する。

アセンブリはマニフェストを含み得るもので、これは、アセンブリ、アセンブリのバージョン、及びかかるアセンブリが参照をする何れの外部アセンブリをも生成する個々のモジュールを特徴づけるものである。マニフェストは、アセンブリの範囲を決定し、リソースとクラスへの接続を実現するのに必要なすべてのメタデータだけではなく、アセンブリのバージョンとアイデンティティのためのアセンブリの要求を指定するために必要なすべてのメタデータも含んでいる。以下のテーブルは、アセンブリのマニフェストに含まれているデータを示す。最初の４要素（頑健な名前データに加えて、アセンブリ、バージョン値、言語と地域パラメータの名前）は、アセンブリのアイデンティティを構成している。

何れの．ＮＥＴアセンブリも、アプリケーションアイコン、グラフィックファイル、オーディオフラグメント又は文字列テーブル等の所要数の埋め込まれたリソースを含み得る。

アセンブリは、いくつかのモジュールで構成される。モジュールとは、アセンブリの一部であり、すなわちコードやリソースの論理集合である。アセンブリにおいて用いられる階層構造は、アセンブリ＞モジュール＞タイプ（クラス、インタフェース、構造体、列挙型、委譲型）＞メソッドである。モジュールは、アセンブリそのものの内部（すなわちアセンブリのファイルの中）にあってもよいし、外部にあってもよい（すなわち、別個のファイル）。モジュールは、エントリポイントを持たないばかりか、何れも個別のバージョン値すら有さない。それゆえ、ＣＬＲ環境によって直接ロードすることはできない。モジュールは、アセンブリのマニフェストを含むファイル等のアセンブリのメインモジュールによってのみロードされ得る。モジュールのマニフェストは、すべての外部アセンブリの列挙型だけを含んでいる。個々のモジュールは、アセンブリの個々のモジュールにおいて書き出されるユニークな識別子であるモジュールバージョン識別子（ＭＶＩＤ：Ｍｏｄｕｌｅ Ｖｅｒｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）を有し、これは個々のコンパイルに際して異なるものである。

図１Ａは、単一ファイルアセンブリのレイアウト一例を示している。図示の通り、単一ファイルアセンブリにおいてすべての要件要素（例えば、ヘッダ、ＣＩＬコード、タイプ、マニフェスト、及び資源のメタデータ）は、単一ファイル中に位置する拡張子が＊．ｅｘｅ又は＊．ｄｌｌのファイルである（以下「＊．ｘｘｘ」とある場合は、拡張子を示すものとする）。

図１Ｂは、複数ファイルアセンブリの一例を示している。複数ファイルアセンブリは、単一の論理演算器という形式で配置され且つ同じバージョン値が所要の．ＮＥＴモジュールのセットから構成される。一般に、これらのモジュールのうちの１つは、メインモジュールと呼ばれ、アセンブリのマニフェストを含み、すべての必要なＣＩＬ指示、メタデータ、ヘッダ、及び追加のリソースも含み得るものである。

メインモジュールのマニフェストは、メインモジュールのオペレーションが従属するすべての他の関連モジュールを示している。複数ファイルアセンブリのセカンダリモジュールは、＊．ｎｅｔｍｏｄｕｌｅを割り当てられる。セカンダリの＊．ｎｅｔｍｏｄｕｌｅモジュールは、外部アセンブリが、所要のモジュールに必要な外部アセンブリが列挙されるモジュールのレベルのマニフェストだけでなくタイプのＣＩＬコード、及びメタデータをも含んでいる。

何れのＰＥファイルでも、アセンブリは、ＰＥファイル又は電子署名されたカタログファイル（＊．ｃａｔ）とともにあり、電子署名（例えばＸ．５０９）がされ得る。頑健な名前の署名を追加で又は別個に用いることもできる。すなわち、アセンブリの内容とＲＳＡ秘密鍵を用いて生成されたハッシュである。ハッシュは、アセンブリにおいてＰＥヘッダとメタデータの間に位置される。ハッシュにより、コンパイルされた以降はアセンブリにおいて変化がないことを確認することができる。単一ファイルアセンブリでは、ファイルがコンパイルされる時にＰＥヘッダの後に空きバイトが残される。ファイルのハッシュは、秘密鍵を用いて計算され、かかる空きバイトに入れられる。

複数ファイルアセンブリでは技術が異なる。アセンブリのメインファイルのハッシュを除き、ハッシュは、外部のモジュール用に計算され、その後においてデータは主要なアセンブリに入れられる。これらのモジュールは、自身の署名を有さず、メインモジュールに由来する種々のＭＶＩＤを有している。以下のアイテムはアセンブリのマニフェストに入れられる：

公開鍵、すなわち頑健な名前の署名の公開鍵。
公開鍵トークン、すなわち頑健な名前の署名の公開鍵部分のハッシュ。

一般に、アセンブリは分ける、プライベートアセンブリとパブリック／共有アセンブリとに分けられる。プライベートアセンブリは、常に使用中クライアントアプリケーション又はそのうちの１つ（すなわち、アプリケーションカタログ）と同一のカタログに置かれる。

これに対して、パブリックアセンブリは、同じ装置のいくつかのアプリケーションにおいて同時に使用され得る。パブリックアセンブリは、それらが使用されるアプリケーションと同一のカタログ中には置かれない。代わりに、グローバルアセンブリキャッシュ（ＧＡＣ：Ｇｌｏｂａｌ Ａｓｓｅｎｂｌｙ Ｃａｃｈｅ）にインストールされる。ＧＡＣは、以下のテーブルに示すようにいくつかの場所に同時に置かれる。
ＧＡＣにインストールされているアセンブリは、頑健な名前を有するとよい。頑健な名前は、СОМにおいて用いられたグローバルユニーク識別子（ＧＵＩＤ：Ｇｌｏｂａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）と同じ現在の．ＮＥＴであればよい。なお、１２８ビット数であるСОМのＧＵＩＤ値とは異なり、．ＮＥＴの頑健な名前は、公開鍵と秘密鍵として知られている２つの相関する暗号鍵に部分的に基づいている。

頑健な名前は、少なくとも以下を含む相関データのセットから構成される。
アセンブリの名前（拡張子を除いたアセンブリの名前）。
アセンブリのバージョン値。
公開鍵の値。
アプリケーションのローカライズに用いる地域指定値（必須ではない）。
アセンブリの内容及び秘密鍵の値から得られたハッシュを用いて生成された電子署名。
アセンブリの頑健な名前を生成するために、ユーザーは、公開鍵及び秘密鍵を入手する。そして、公開鍵及び秘密鍵のデータは、例えば．ＮＥＴフレームワークＳＤＫの一部として提供されるユーティリティであるＳｎ．ｅｘｅにより生成される。このユーティリティが、異なるものであるが数学的には関連する鍵（公開鍵及び秘密鍵）のデータを含むファイルを生成する。このファイルの位置は、コンパイラによって示され、それはアセンブリのマニフェストにおいて公開鍵の全値を書き出す。

特定のケースにおいては、コンパイラは、アセンブリの全体の内容（例えば、ＣＩＬコード、メタデータなど）に基づいて対応するハッシュを生成する。このハッシュは、固定の入力データに対して統計的に一意に定まる数値である。その結果、．ＮＥＴアセンブリ（文字列の単一の文字でさえ）のあらゆるデータの変化に際して、コンパイラは異なるハッシュを生成する。生成されたハッシュは、その時、ＣＬＲヘッダデータ中のアセンブリに挿入された電子署名を得るためにファイル中に含まれている秘密鍵データと結合する。

図１Ｃは、頑健な名前を生成するための処理一例を示している。一般に、秘密鍵データはマニフェストにおいて示されるものではなく、（生成されたハッシュとともに）電子署名によってアセンブリの内容を識別するためにのみ使われる。頑健な名前を生成し割り当てる処理の完了後に、アセンブリはＧＡＣにインストールされる。

例えば、ＧＡＣのアセンブリへのパスは、
Ｃ：￥Ｗｉｎｄｏｗｓ￥ａｓｓｅｍｂｌｙ￥ＧＡＣ＿３２￥ＫａｓｐｅｒｓｋｙＬａｂ￥２．０．０．０＿＿ｂ０３ｆ５ｆ７ｆ１１ｄ５０ａ３ａ￥ＫａｓｐｅｒｓｋｙＬａｂ．ｄｌｌ
であるとする。
Ｃ：￥Ｗｉｎｄｏｗｓ￥ａｓｓｅｍｂｌｙは、ＧＡＣのパスである。
ＧＡＣ＿３２は、プロセッサのＧＡＣアーキテクチャである。
￥ＫａｓｐｅｒｓｋｙＬａｂは、アセンブリの名前である。
￥２．０．０．０＿＿ｂ０３ｆ５ｆ７ｆ１１ｄ５０ａ３ａは、アセンブリ公開鍵メーカーのバージョンである。
ＫａｓｐｅｒｓｋｙＬａｂ．ｄｌｌは、アセンブリの名前とその拡張子である。

特定のケースには、アセンブリコードが次のように実行される。まず、どちらの処理（３２又は６４ビット）で実行開始すべきかを決定するためにＰＥヘッダが分析される。次に、選択されたファイルバージョンであるＭＳＣｏｒＥＥ．ｄｌｌがロードされる（この場合は、３２ビットシステム用である、Ｃ：￥Ｗｉｎｄｏｗｓ￥Ｓｙｓｔｅｍ３２￥ＭＳＣｏｒＥＥ．ｄｌｌ）。アセンブリのソースコードの例は、次の通りである。

ｓｔａｔｉｃ ｖｏｉｄ Ｍａｉｎ（）
｛
Ｓｙｓｔｅｍ．Ｃｏｎｓｏｌｅ．ＷｒｉｔｅＬｉｎｅ（"Ｋａｓｐｅｒｓｋｙ"）；
Ｓｙｓｔｅｍ．Ｃｏｎｓｏｌｅ．ＷｒｉｔｅＬｉｎｅ（"Ｌａｂ"）；
｝

メソッドＳｙｓｔｅｍ．Ｃｏｎｓｏｌｅ．ＷｒｉｔｅＬｉｎｅ（"Ｋａｓｐｅｒｓｋｙ"）等のメソッド（便宜上、コードはそのオリジナルの形において示されて、ＣＩＬコードにコンパイルされない）を実行するために、ＪＩＴコンパイラは、СＩＬコードをマシンコマンドに変換する。

図２は、アセンブリコードを実行するメソッドを一例を示している。まず、Ｍａｉｎ（）関数を実行する前に、ＣＬＲ環境はすべての宣言されたタイプ（クラス）を特定する（例えばタイプコンソール）。次に、ＣＬＲ環境がメソッドを決定し、これらを統合した「構造体」（タイプコンソールにおいて定義されるような各々のメソッド）中のレコードにおいて結合する。エントリは、メソッドの実行があり得るアドレスを含んでいる。メソッドＷｒｉｔｅＬｉｎｅへの第１アクセスでは、ＪＩＴコンパイラが呼び出される。ＪＩＴコンパイラは、呼び出し中のメソッド及びこのメソッドを定義するタイプに着目する。いったん呼びだされたら、対応するアセンブリのメタデータにおいて、ＪＩＴコンパイラは、メソッドコード（すなわち、メソッドＷｒｉｔｅＬｉｎｅ（ｓｔｒｉｎｇ ｓｔｒ）を実行するコード）の実行を求める。ＪＩＴコンパイラは、その時機械語にＣＩＬコードをコンパイルし、コンパイルされたコードを動的なメモリーに保存する。次に、ＪＩＴコンパイラは、タイプデータ（コンソール）内部の「構造体」に戻り、呼び出し中のメソッドのアドレスとメモリセクションのアドレスとを機械語を用いて取り替える。メソッドＭａｉｎ（）は、再びメソッドＷｒｉｔｅＬｉｎｅ（ｓｔｒｉｎｇ ｓｔｒ）にアクセスする。コードがすでにコンパイルされているので、かかるアクセスは、ＪＩＴコンパイラの呼び出しを要しない。メソッドＷｒｉｔｅＬｉｎｅ（ｓｔｒｉｎｇ ｓｔｒ）の実行後、メインメソッドに戻る。

ＪＩＴコンパイラがＣＩＬコードをプロセッサの指示に変換すると、最初の呼び出し時は、関数が「ゆっくり」としか機能しない。別の例ではすべて、コードはもともとメモリ内にあり所要のプロセッサ用に最適化されて提供される。しかし、別のプログラムが別の処理において開始されたときは、ＪＩＴコンパイラはこのメソッド用に再び呼び出されることとなる。

上述のネイティブイメージは、最初の呼び出し時に関数がゆっくり動作する問題を解決する。アセンブリがロードされる時には、機械語が実行されるイメージがロードされる。このテクノロジーを使うことで、アプリケーションのロード及び実行を高速化することが可能となる。なぜなら、ＪＩＴコンパイラは、何もコンパイルする必要がなく、及び／又は、毎回データ構造体を生成する必要もないからである。これらのすべてはイメージから取り去られる。ＧＡＣにインストールされるかどうかに関わらず、イメージは、どのような所要の．ＮＥＴアセンブリに対しても生成できる。コンパイルのための一例としては、以下のパスにあるユーティリティであるｎｇｅｎ．ｅｘｅが用いられる。
％ＷＩＮＤＩＲ％￥Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ￥フレームワーク￥＆ｌｔ；フレームワーク＿ｖｅｒｓｉｏｎ＆ｇｔ；￥ｎｇｅｎ．ｅｘｅ
ｎｇｅｎ．ｅｘｅが開始されると、アセンブリのＣＩＬコードのために、ＪＩＴコンパイラを用いて機械語が生成され、その結果はネイティブイメージキャッシュ（ＮＩＣ：Ｎａｔｉｖｅ Ｉｍａｇｅ Ｃａｃｈｅ）のディスクに保存される。コンパイルは、そのソフトウェアとハードウェアの構成を考慮しローカル機器においてなされる。それゆえ、イメージは、それがコンパイルされた環境においてのみ用いられるとよい。このようなイメージを生成している目的は、管理アプリケーションの有効性を向上させることにある。すなわち、機械語で生成されたアセンブリがＪＩＴコンパイルの代わりにロードされる。

アセンブリのコードが多くのアプリケーションによって使用されると、イメージが多くのアプリケーションにより同時に使われるようになるので、イメージが生成され、アプリケーションの立ち上げ及び実行速度を大幅に向上させる。また、ＪＩＴコンパイラによってオンザフライで生成されたコードは、コンパイルされるアプリケーションのコピーによってのみ用いられる。

例えば、以下に示すようなコンパイル可能なイメージへのパスが形成される：
Ｃ：￥Ｗｉｎｄｏｗｓ￥ａｓｓｅｍｂｌｙ￥ＮａｔｉｖｅＩｍａｇｅｓ＿ｖ４．０．３０３１９＿３２￥Ｋａｓｐｅｒｓｋｙ￥９ｃ８７ｆ３２７８６６ｆ５３ａｅｃ６８ｄ４ｆｅｅ４０ｃｄｅ３３ｄ￥Ｋａｓｐｅｒｓｋｙ．ｎｉ．ｄｌｌ，
Ｃ：￥Ｗｉｎｄｏｗｓ￥ａｓｓｅｍｂｌｙ￥ＮａｔｉｖｅＩｍａｇｅｓは、システムのイメージキャッシュへのパスである；
ｖ４．０．３０３１９＿３２は、．ＮＥＴフレームワークのバージョンとプロセッサアーキテクチャ（３２又は６４ビット）を示している。
Ｋａｓｐｅｒｓｋｙは、分かりやすく示したアセンブリの名前である。
９ｃ８７ｆ３２７８６６ｆ５３ａｅｃ６８ｄ４ｆｅｅ４０ｃｄｅ３３ｄは、アプリケーションのハッシュである。
Ｋａｓｐｅｒｓｋｙ．ｎｉ．ｄｌｌは、アセンブリの名前と拡張子である。
アセンブリの機械語のイメージを生成する時には、ｎｇｅｎ．ｅｘｅが以下のレジストリ（分岐あり）に保存される。
６４ビットアプリケーション用：
ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ￥ＳＯＦＴＷＡＲＥ￥Ｍｉｃｒｏｓｏｆｔ￥．ＮＥＴフレームワーク￥ｖ２．０．５０７２７￥ＮＧｅｎＳｅｒｖｉｃｅ￥３２ビットアプリケーション用：ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ￥ＳＯＦＴＷＡＲＥ￥Ｗｏｗ６４３２Ｎｏｄｅ￥Ｍｉｃｒｏｓｏｆｔ￥．ＮＥＴフレームワーク￥ｖ２．０．５０７２７￥ＮＧｅｎＳｅｒｖｉｃｅ￥Ｒｏｏｔｓ￥．

ＧＡＣに置かれたアセンブリに対してイメージがインストールされた場合は、以下の分岐が呼び出される。...￥Ｒｏｏｔｓ￥Ａｃｃｅｓｓｉｂｉｌｉｔｙ，Ｖｅｒｓｉｏｎ＝２．０．０．０，Ｃｕｌｔｕｒｅ＝Ｎｅｕｔｒａｌ，ＰｕｂｌｉｃＫｅｙＴｏｋｅｎ＝ｂ０３ｆ５ｆ７ｆ１１ｄ５０ａ３ａ，ｐｒｏｃｅｓｓｏｒＡｒｃｈｉｔｅｃｔｕｒｅ＝ｍｓｉｌ．
当該アセンブリがＧＡＣにインストールされなかったならば、以下の分岐が呼び出される。
...￥Ｒｏｏｔｓ￥Ｃ：／Ｐｒｏｇｒａｍ Ｆｉｌｅｓ（ｘ８６）／ＡＴＩ Ｔｅｃｈｎｏｌｏｇｉｅｓ／ＡＴＩ．ＡＣＥ／Ｃｏｒｅ−Ｓｔａｔｉｃ／Ａ４．Ｆｏｕｎｄａｔｉｏｎ．ＤＬＬ

Ｗｉｎｄｏｗｓ８以前では、開発者は、アセンブリイメージの生成、アップデート及び除去を、ｎｇｅｎ．ｅｘｅを使用させること（又はインストーラを設定すること）で、常に自分自身で行わなければならなかった。Ｗｉｎｄｏｗｓ８では、イメージを一定のＷｉｎｄｏｗｓアセンブリのために自動的に生成できるようになっている。

あるケースでは、ネイティブイメージサービスは、イメージを制御するものとなる。これにより、機器が既に立ち上がっている場合、開発者は、機械語のイメージのインストール、アップデート、及び除去を後で実行するように後回しにすることができる。ネイティブイメージサービスは、アプリケーションやアップデートをインストールをするプログラムによって開始される。これは、ユーティリティｎｇｅｎ．ｅｘｅによって実行される。このサービスは、Ｗｉｎｄｏｗｓのレジストリに保存され且つそれぞれが個別の優先順位を有するリクエストキュー（Ｒｅｑｕｅｓｔ Ｑｕｅ）によって動作する。この優先順位とは、いつタスクを実行するかを決定するものである。

別のある例では、機械語のイメージは、開発者又は管理者の主導によるものだけではなく、．ＮＥＴフレームワークプラットフォームによって自動的にも生成される。．ＮＥＴフレームワークプラットフォームは、ＪＩＴコンパイラのタスクをトラッキングしてイメージを自動的に生成する。一般に、アプリケーションの動作中にイメージを生成するのは非常に長い時間がかかるため、この操作はしばしば後に実行される。換言すると、ＣＬＲ環境は、タスクをキューに追加し、機器の停止中にそれらを実行することになる。

ＣＬＲ環境は、アセンブリバインディングモジュール（アセンブリをまとめるモジュール、すなわちアセンブリバインダ）を使い、これにより実行のタイミングを読み込むアセンブリを探し出し、それに対応するアセンブリを実行する。ＣＬＲは何種類かのバインディングモジュールを使うことができる。イメージバインディングモジュール（すなわち、ネイティブバインダ）は、イメージを検索するものである。所望イメージの検索は、２つの段階において実行されることとなる。第１に、所要のモジュールがファイルシステムにおいてアセンブリとイメージとを識別する。第２に、所要のモジュールは、アセンブリとイメージとの対応関係をチェックする。

図３は、バインディングモジュールを動作方法を示している。ステップ３１０において、アセンブリバインディングモジュールは、アセンブリを検索する。この検索は、検索されるアセンブリ自体は署名されるもののその内容が読まれないことが前提であるが、ＧＡＣとアセンブリが開かれメタデータが読み込まれるアプリケーションカタログとにおいて実行される。

次に、ステップ３２０では、イメージバインディングモジュールが識別されたアセンブリに対応するＮＩＣのイメージを検索する。イメージが識別される場合には、ステップ３３０でチェックされて、ステップ３４０においてイメージバインディングモジュールがイメージから必要なデータとメタデータを読み込む。これにより、イメージが以下を含む慎重な分析（ただし以下に限定するものではない）を実行するための一定の標準を満たしていることが保証される。

頑健な名前、
生成時間（イメージはアセンブリよりも後であることが好ましい）、
アセンブリとイメージのＭＶＩＤ、
．ＮＥＴフレームワークのバージョン、
プロセッサアーキテクチャ、
関連するイメージのバージョン（例えばｉｍａｇｅ ｍｓｃｏｒｌｉｂ．ｄｌｌ）。

アセンブリが頑健な名前を有さない場合は、ＭＶＩＤがチェックのために用いられる。ステップ３５０では、分析によりそのイメージがカレント（「現在作業中」の意）かどうかが決定されて、カレントでなければ、ステップ３７０でコントロールがＪＩＴコンパイラに転送される。カレントであれば、ステップ３６０でイメージからコードがロードされる。

上述の説明から分かるように、ネイティブイメージの数がアセンブリの数を大幅に越え、同じ親アセンブリにより生成されたネイティブイメージは、他と機器やイメージのバージョンが異なり得る。それらの全てはイメージを分類するタスクを複雑にするものである。いくつかの従来のファイル分類メソッドは、クラウドサービス等を使用するものだが、イメージを正しく効率的に分類する良い方法がない。

これより、 コンピュータ機器におけるオペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセスをコントロールするための例示的なシステム、方法及びコンピュータプログラム製品を開示する。特に、本開示されるシステムと方法は、未信頼のネイティブイメージのアクセスをオペレーティング・システムのリソースに制限してコンピュータ機器のセキュリティを増大させる。

ある観点では、機器のオペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセスを制御する方法は、ハードウェアプロセッサによって、機械語のネイティブイメージを取得する工程と、前記ハードウェアプロセッサによって、前記ネイティブイメージが生成された親アセンブリを識別する工程と、前記ハードウェアプロセッサによって、親アセンブリの信頼カテゴリーを決定する工程と、前記親アセンブリの前記信頼カテゴリーに基づいて、前記ハードウェアプロセッサによって前記ネイティブイメージの前記信頼カテゴリーを決定する工程と、前記ハードウェアプロセッサによって、信頼カテゴリーが未信頼である前記ネイティブイメージのアクセスを機器のオペレーティング・システムのリソースに制限する工程とを備える。

別の観点においては、前記ネイティブイメージの信頼カテゴリーが前記親アセンブリの信頼カテゴリーと対応する。

別の観点においては、かかる方法は、前記ネイティブイメージと前記親アセンブリの間の対応を決定する工程と、前記決定された対応に基づいて、前記ネイティブイメージが修正されたか否かを決定する工程とを更に備える。

別の観点においては、機器のオペレーティング・システムのリソースに対して機械語のネイティブイメージのアクセスを制御するためのシステムは、ハードウェアプロセッサを備え、前記ハードウェアプロセッサは、書き込みアクセスを機械語のネイティブイメージに制限し、前記書き込みアクセスを制限されたネイティブイメージを生成するために使用した親アセンブリを識別し、前記親アセンブリに基づき、前記ネイティブイメージをアップデートし、前記親アセンブリの信頼カテゴリーを決定し、前記親アセンブリの信頼カテゴリーを、アップデートされた前記ネイティブイメージに割り当て、前記信頼カテゴリーが未信頼であるアップデートされたネイティブイメージのアクセスを前記機器のオペレーティング・システムのリソースに制限するように構成される。

別の観点においては、書き込みアクセスがｎｇｅｎ．ｅｘｅを除くすべての処理に制限される。

別の観点においては、前記機械語の前記ネイティブイメージのアップデートは、前記書き込みアクセスを制限された前記ネイティブイメージを前記親アセンブリの前記機械語の新しいネイティブイメージに交換する工程を含む。

上述の発明の概要は、本発明の基本的な理解において役立つものである。発明の概要は、考え得る全ての詳細な概要ではなく、すべての実施形態のキーや重要要素を特定する意図も本発明のあらゆるすべての実施形態の範囲を示す意図もない。唯一の目的は、これら示す本発明のより詳細な説明に対し前置き的に１つ又は複数の実施形態を示すことである。このため、本発明の１つ又は複数の実施形態は、特許請求の範囲において説明され例示された機能を含む。

添付の図面は、本明細書の一部として組み入れられ、この指定の一部を構成し、発明の詳細な説明とともに本発明の１つ又は複数の例面を説明し、それらの原理と実施を説明するのに役立ち得るものである。

単一ファイルアセンブリのレイアウト一例を説明する図である。 複数ファイルアセンブリの一例を示す図である。 頑健な名前を生成する処理の一例を示す図である。 アセンブリコードを実行するメソッドの一例を示す図である。 バインディングモジュールを操作するメソッドを示す図である。 一例に係るイメージを分類するメソッドの一例を示す図である。 一例に係るイメージの構造の一例を示す図である。 一例に係り、イメージにカテゴリーを割り当てるメソッド一例を示す図である。 本発明に係るシステムと方法が実装できる汎用計算機システムの一例を示す図である。

例示する実施形態は以下、機器のオペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセス制御のためのシステム、メソッド、及びコンピュータプログラム製品として説明される。当業者であれば、以下の記載はあくまでも例示であり、あらゆる制限をも意図するものではないことは当然に意味するところである。本発明が利益となる分野の当業者であれば、別例をも容易に示唆されることであろう。添付の図面ではその詳細を示すための参照符号が付されている。図面と以下の記載において、同一の又はそれに相当するものについては、同一の参照符号を用いるものとする。

図４は、一例に係るイメージ分類方法の一例を示している。図示の通りステップ４００ではイメージが得られる。一例では、イメージは、ネイティブイメージキャッシュ（ＮＩＣ：Ｎａｔｉｖｅ Ｉｍａｇｅ Ｃａｃｈｅ）から得られる（例えば、イメージが機器にインストールされて使用される意図がある場合）。別例では、イメージは、いずれの他のイメージリポジトリからでも得られ得る（機器がストレージとして使われている場合やイメージが意図する機器において使われていない場合）。次に、ステップ４１０では、イメージの信頼カテゴリーが決定される。一例において、リクエストがデータベースに生成され、信頼のイメージのカテゴリーが決定される。ここでイメージのチェックサムが使われ得る。別例では、イメージのＭＶＩＤが使われ得る。また、イメージのカテゴリーを決定するためにテンプレートが使用される。テンプレートの動作メカニズムを以下詳述する。

イメージがデータベースにない場合は、ステップ４２０においてイメージを生成した親アセンブリが決定される。親アセンブリを決定するために、少なくとも以下のデータ、データ構造体、及びメカニズム（ＭＶＩＤ、レジストリー（例えば、Ｗｉｎｄｏｗｓレジストリー）、バインディングモジュール、及び頑健な名前）が使われ得る。

例えば、データベースが存在し、カレントの機器にあるアセンブリのＭＶＩＤを含んでいる場合、ある実施形態ではＭＶＩＤによって決定することができる。かかる実施形態では、イメージのＭＶＩＤは、アセンブリのＭＶＩＤを含んでいるデータベースにおいて識別され得る。

別例では、イメージの生成中にレジストリーの入力が生成される時には、親アセンブリはレジストリーでの入力により決定され得る。かかる入力の例の詳細は、上述の通りである。一例では、入力は、親アセンブリへのパスについての情報、ネイティブイメージ及び様々な付随的なデータについての情報を含み得る。レジストリーから得られたデータと分析されたイメージから得られたデータとの比較によって、親アセンブリを識別することができる。

別例では、親アセンブリは、頑健に名付けられたアセンブリから生成されたイメージに対して使用される頑健な名前から決定することができる。親アセンブリの頑健な名前のコンポーネントは、イメージから抽出され、頑健な名前が生成され、そしてかかるデータに基づいて、機器のＧＡＣ又はアセンブリを強い名前に基づく所定順に保存しているデータベースで、親アセンブリに対するパスが決定される。

親アセンブリを決定する処理は、多くの要因に依存する。例えば、親アセンブリ及びイメージの場所（例えば、ユーザーの機器、又はリモート／ローカルのデータベース）、ストレージのそれらの場所でのアセンブリとイメージが危険状態（Ｃｏｍｐｒｏｍｉｓｅ）である可能性、アセンブリ（頑健な名前又は普通の名前）を命名する方法が挙げられ得る。

一例において、親アセンブリが決定された後に、ステップ４２１においてネイティブイメージとアセンブリとの間の対応が決定される。もしストレージにおいて、承認なし（例えば、それが危険状態であったり汚染されていたりする等）で、ネイティブイメージが生成後に変更され得た可能性がある場合には、このステップが実行される。一例では、アルゴリズムを使用することができ、これにより上述のイメージバインディングモジュールを使用する対応が決定される。別例では、親アセンブリが決定された後に、このアセンブリからのイメージ（すなわち、変更が無いことが保証されているイメージであるオリジナルネイティブイメージ）を生成することができて、対応を決定するために分析されるネイティブイメージと直接比較することができる。一例において、かかる比較はバイト単位で実行することができる。

一例においては、イメージの承認の無いの変更を防止するために、例えばｎｇｅｎ．ｅｘｅ等、信頼できる処理にのみイメージの修正を許可し、その間はネイティブイメージからはデータの読み出ししか許可されないものとする。

一例において、テンプレートのメカニズムによって、イメージと親アセンブリの間の対応を決定することができる。一例において、親アセンブリ及び対応するネイティブイメージが全く対応しない場合は、イメージが危険状態にある（すなわち悪い状態）と考えられる。危険状態にあるイメージは、ＣＩＬコード、機械語、タイプのメタデータ、ＣＬＲ及びＰＥヘッダに含まれる情報に関して、オリジナルイメージと異なる可能性がある。

図５は、一例に係るネイティブイメージの構造一例を示している。親アセンブリのようなネイティブイメージは、所定の構造を有する。例えば、ＡｓｓｅｍｂｌｙＫａｓｐｅｒｓｋｙＬａｂ．ｄｌｌとＩｍａｇｅＫａｓｐｅｒｓｋｙＬａｂ．ｎｉ．ｄｌｌは、メタデータ及びコードを含んでおり、かかるアセンブリはＣＩＬコードを独占的に含んでいる。一方で、特定の実施形態ではネイティブイメージが機械語と構造体であるＮａｔｉｖｅＩｍａｇｅＨｅａｄｅｒをも含んでいる。構造体、メタデータ、及びコードに基づいて、上述のテンプレートＫａｓｐｅｒｓｋｙＬａｂ．ｄｌｌ．ｔｍｐｌが生成されて、生成された親アセンブリとイメージとに関連づけられる（すなわち、対応づけがなされる）。テンプレートに、構造、コード、及びメタデータをバインディングするために、かかるシステム及び方法の一例では、例えばインテリジェントハッシュテクニック（ローカルセンシティブハッシュとして知られている）が用いられる。一例では、図５に示すようにテンプレートが生成される。

より具体的には、データ（すなわち、マニフェスト、メタデータ、ＣＩＬコード等）が、アセンブリから抽出される。機械語同様、同じデータは、ネイティブイメージから抽出される。同じ親アセンブリから生成されたイメージの可能なバージョンそれぞれに対しては不変のデータは処理されて（例えば、チェック・サムはそこから計算される）、ハッシュが形成されてテンプレートに置かれる。機械語のように、イメージのバージョンごとに異なるデータも処理され、それに応じてインテリジェントハッシュが生成される。特定の実施形態では、機械語のためのファンクションコールジャーナルが生成され、分けられた機械語を有するリスト又は所要の機械語の実装のロジックを反映している何らかのもの（エンティティ：Ｅｎｔｉｔｙ）、及びインテリジェントハッシュが、かかるエンティティから形成される。別例では、これらのエンティティはテンプレートにおいて直接使われる。機器のソフトウェア及びハードウェア構成に依存しているイメージのバージョンを問わず、親アセンブリとイメージを明確に関連づける（対応づける）ためのテンプレートが形成されることに留意し得る。イメージの機械語で変化が起こってイメージコードの実行ロジックがアセンブリコードの実行ロジックと対応しない場合には、テンプレートに基づいて、親アセンブリとイメージの対応がなく、イメージは、アセンブリと対応していないと決定される。

テンプレートを用いる対応有無の判定例を、以下詳述するものとする。例えば、ある親アセンブリＫａｓｐｅｒｓｋｙ．ｄｌｌが存在する場合、その機器にイメージＫａｓｐｅｒｓｋｙ．ｎｉ．ｄｌｌが生成される。テンプレートＫａｓｐｅｒｓｋｙ．ｄｌｌ．ｔｍｐｌが形成されて、これにより親アセンブリとイメージとが対応づけられる。そして、機器において、ソフトウェアとハードウェアはアップデートされて（すなわち、オペレーティング・システム、．ＮＥＴフレームワーク、プロセッサの交換等のアップデート）、イメージＫａｓｐｅｒｓｋｙ．ｎｉ．ｄｌｌのバージョンは、カレントでないものとされる。したがって、イメージは使えなくなり、このイメージのアップデートが開始され、新しいイメージＫａｓｐｅｒｓｋｙ．ｎｉ．ｄｌｌが生成される。そして、それは前のバージョンのイメージと異なる。テンプレートが使われる時には、親アセンブリに対応するアップデートされたイメージ（すなわち、機械語の実行ロジックは同じままである）を見つける。別のケースでは、悪意に満ちたプログラムであってイメージＫａｓｐｅｒｓｋｙ．ｎｉ．ｄｌｌを修正してしまうプログラムを機器にインストールであって。この例において、テンプレートが使われる時には、悪意に満ちたプログラムにより修正されたイメージは、親アセンブリに対応しない（例えば、機械語の実行のロジックは親アセンブリに埋め込まれたロジックと異なる）。

図４に示すように親アセンブリを決定した後に、アセンブリの信頼カテゴリーが設定される（ステップ４３０）。アセンブリの信頼カテゴリーは、アンチウィルスアプリケーションなどの機器の保護システムにおける（信頼済又は未信頼の）アセンブリでの信頼の度合いである。実施形態では、２つの可能なアセンブリのカテゴリーがある、すなわち、信頼済みのアセンブリ又は未信頼のアセンブリである。本発明の文脈において、アセンブリのカテゴリーの概念をアセンブリの危険ステータスの概念と区別し得る。本発明の文脈におけるアセンブリの危険ステータスは、危険又は非危険である。危険ステータスとされていない不明のアセンブリもあり得る。アセンブリの危険ステータスは、そのアセンブリがインストールされる機器に対してアセンブリの危険度合いを決定づけるものである。機器へのアセンブリの危険は、一例、機器からのデータの窃盗の可能性、データの代用、又はアセンブリのコードの実行の間の機器のソフトウェアの無許可の部分修正において含む。

信頼済みのアセンブリは、保護システムのには危険ではないと判定されたアセンブリを含む。特に、機器の保護システムは、アセンブリに対して信頼済みのカテゴリーを割り当てる際に、カレント状態機器において、及びアセンブリについての情報に基づいてローカルで機能する。ある実施形態では、かかる情報をアセンブリの危険ステータスとして用いる。アセンブリの危険ステータスは、アセンブリのＭＶＩＤ、アセンブリの頑健な名前、アセンブリと同類のチェック・サムなど、アセンブリの識別情報を使って決定され得る。これのために、ステップ４３１においてリクエストが評判データベースに追加される。ある実施形態では、データベースはアセンブリが保存されている機器にあり、別例では、リモートで使用する。アセンブリが既知ならば（すなわち、それについての情報は評判データベースに含まれている）、かかるアセンブリは、非危険又は危険であるという危険ステータスを有する。従って評判データベースからの情報に依存して、を持っている。のすでに危険ステータスアセンブリの識別情報がデータベースに含まれていないな場合は、アセンブリは不明であると考えられ。すなわち、アセンブリはステータスを有さない。（すなわち、未確定のステータス）アセンブリが、非危険ステータスを有する場合は、一例において、アセンブリは信頼済みカテゴリーを受け取る。別例では、アセンブリのカテゴリーは、例えば、危険ステータスであると分かっているインストールパッケージでアセンブリを機器又はその周辺物にインストールすることによって、そのアセンブリについての事実的と統計的情報から決定される。

一例では、アセンブリについての実際の情報は、電子署名についての情報である（例えば、署名の頑健な名前又はＸ．５０９）。このケースでは、電子署名が認証されることとなる。例えば、ステップ４３２での認証のために、識別情報は、アセンブリの電子署名について得られ、これは例えばそこからメーカーやファイルのハッシュ又はその一部を情報として含んでいる。署名はアセンブリ又はカタログに置かれてもよい（すなわち、カタログ署名）。アセンブリの電子署名の危険ステータスは、署名の識別情報を用いて決定され、これは問い合わせを評判データベースを組み込むものである。署名が既知（すなわち、署名についての情報が評判データベースに含まれている）の場合、その署名はすでに非危険又は危険のステータスを有するものとなっている。署名の識別情報がデータベースに含まれていない場合は、署名は不明であると考えられてすなわち、署名はステータスを持っていない（すなわち、ステータス未知）。一例において、署名が非危険のステータスを有する場合、一例において、アセンブリには信頼済みカテゴリーが与えられる。署名が危険ステータスを有する場合は、一例において、アセンブリは未信頼カテゴリーが与えられる。

ステータスは、署名に様々な方法で割り当てられる。一例において、署名のステータスは、メーカーに依存する。別例では、署名のステータスは、インストーラから継承されて割り当てられ、その署名ステータスは既知である。別例において、署名のステータスは、署名の人気度（Ｐｏｐｕｌａｒｉｔｙ）に依存して割り当てられ、例えばより人気度の高い署名に、より高いレベルのステータスが割り当てられる。

一例において、ステップ４３３では、信頼カテゴリーは、アセンブリのアンチウィルスチェックにより決定される。これには、悪意のあるプログラムを検出するために、署名、学習、統計等を含む様々なメソッドが使用される。この実施形態において、アセンブリが、アンチウィルスチェックの結果から非危険であると認定されると、アセンブリは信頼済みカテゴリーを受け取ることとなる。そうでない場合は未信頼とされる。

アセンブリの信頼カテゴリーを決定した後に、ステップ４４０、イメージの信頼カテゴリーにおいて決定する。一例において、イメージは、親アセンブリのために決定された信頼カテゴリーを割り当てられる。別例では、イメージのカテゴリーは、上記ステップ４１０のメソッドにより決定される。

保護システムが機器にインストールされると、かかるシステム及び方法により、例示の実施形態に基づきイメージのリポジトリーは、認可なくで変更されておらず又今後もされないことが確認できる。

図６は、カテゴリーをイメージに割り当てる方法の一例を示している。図示の通り、ステップ６００において、イメージのリポジトリーに又は少なくとも１つのイメージにアクセスが制限される。一例には、かかる制限は、イメージを修正するための信頼済みの処理又はその個数を許可するものである。例えばｎｇｅｎ．ｅｘｅのみを許可し、他の処理は読み込みしか許可しないものとすればよい。別例では、かかる制限は、全体の又は少なくとも１つのイメージに対して、リポジトリーへの書き込みアクセスの全制限を含む。

次に、ステップ６１０において、アクセスが制限されたイメージを生成するのに用いる親アセンブリが決定される。ステップ６２０において、少なくとも１つのイメージがアップデートされる（例えば、別のイメージに置換えられる）。一例では、アップデートとは、以前に生成されたイメージを取り除き、オペレーティング・システムによって新しいイメージを生成（例えば親アセンブリのｎｇｅｎ．ｅｘｅを動作させること又は自動イメージ生成サービスによって）するものを含む。別例では、機械語等のイメージデータの一部だけがアップデートされ、これは信頼済みの処理によってなされる。第１のケースにおいては、除去後のイメージが改めて生成される。一例では、これは直ちに実行される。別例では、一定時間、例えばステップ６１０において決定されるアセンブリであってアップデートされるイメージの親アセンブリの動作まで延期される。ステップ６３０において、親アセンブリのカテゴリーがイメージに割り当てられる。

アンチウィルスアプリケーションは、その操作の信頼カテゴリーを用いる。例えば、未信頼の信頼カテゴリーを有するネイティブイメージを取り除く。或いは、例えば、オペレーティング・システムにより提供されるリソースへのアクセスを制限する等、大幅にその使用を制限する。

一例において、アンチウィルスアプリケーションは、検出された親アセンブリのアンチウィルススキャンを実行することができ、機械語のネイティブイメージをアンチウィルス分析から排除しつつ機械語のネイティブイメージによって親アセンブリのアンチウィルススキャンを関連付けることができる。親アセンブリだけがスキャンされる場合、これはコンピュータシステムのアンチウィルス分析の性能を向上させる。そこから生成された機械語のネイティブイメージは、信頼カテゴリー及び／又はアセンブリの危険ステータス（評決）を引き継ぐ。このため、ネイティブイメージのアンチウィルススキャンが実行されない。

図７は、一例に基づいて実施されるシステムとメソッドとが開示される汎用計算機システム（パソコンやサーバー等）の例を示している。図示の通り、コンピュータシステムは、中央演算処理装置２１、中央演算処理装置２１と関連づけられたメモリーを含む様々なシステムコンポーネントを接続するシステムメモリー２２とシステムバス２３を含む。システムバス２３は、従来技術に係る既知のバス構造のように実現され、バスメモリー又はバスメモリーコントローラ、周辺のバス、及びローカルバスを含んでいる。これは、他の何れのバスアーキテクチャとも通信可能である。システムメモリーは、永久メモリー（ＲＯＭ）２４及びランダムアクセスメモリー（ＲＡＭ）２５を含む。基本的な入出力システム（ＢＩＯＳ）２６は、ＲＯＭ２４を用いてオペレーティング・システムをロードするとき等、パソコン２０の要素間の情報伝達を担う基本的な手続を含む。

パソコン２０は、データの読み書きのためのハードディスク２７、取り外し可能な磁気ディスク２９の読み書きのための磁気ディスクドライブ２８、及びＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、その他の光学メディア等の光学ディスク３１の読み書きのための光学式ドライブ３０を含む。ハードディスク２７、磁気ディスクドライブ２８、及び光学式のドライブ３０は、ハードディスクインタフェース３２、磁気ディスクインタフェース３３、及び光学式のドライブインタフェース３４それぞれを横切るシステムバス２３と接続される。ドライブ及び対応するコンピュータ情報メディアは、計算機命令、データ構造体、プログラムモジュール、及びパソコン２０の他のデータのストレージのための電源依存のモジュールである。

本発明は、ハードディスク２７、取り外し可能な磁気ディスク２９及び取り外し可能な光ディスク３１を用いるシステムの実装を提供するものだが、コンピュータに読み込み可能な形式でデータを保存できるフラッシュメモリカード、デジタルのディスク、ランダムアクセスのメモリー（ＲＡＭ）等の他のタイプのコンピュータ情報メディア５６を使用してもよいことに留意されたし。また、これはコントローラ５５を介してシステムバス２３に接続される。

コンピュータ２０は、ファイルシステム３６を有し、記録されたオペレーティング・システム３５の保持する。また追加のプログラムアプリケーション３７、他のプログラムモジュール３８、及びプログラムデータ３９を有する。ユーザーは、入力デバイス（キーボード４０、マウス４２）を用いてコマンドと情報をパソコン２０に入力することができる。他の入力デバイス（不図示）：マイクロフォン、ジョイスティック、ゲームコントローラ、スキャナなどを用いることもできる。そのような入力デバイスは、通常、システムバスに次々接続しているシリアルポート４６を通じてコンピュータシステム２０に差し込まれるが、それらは、他の方法例えばパラレル・ポート、ゲームポート、又は一般的なシリアルバス（ＵＳＢ）に接続される。ディスプレイ機器のモニタ４７又は他のタイプは、また、ビデオアダプタ４８などのインタフェースと交差するシステムバス２３に接続している。モニタ４７に加えて、パソコンは、スピーカー、プリンタ等の他の周辺の出力デバイス（不図示）を接続できる。

パソコン２０は、１つ又は複数のリモートコンピュータ４９とのネットワーク接続を用いて、ネットワーク環境で操作することができる。リモートコンピュータ（又はコンピュータ）４９は、図４に示すように、パソコン２０の性質として説明した上述の要素すべての大多数を有するパソコン又はサーバーでもある。ルータ、ネットワークステーション、ピア接続の機器、又は他のネットワークノードなどの他の機器もまた、かかるコンピュータネットワークで存在し得るものである。

ネットワーク接続は、ローカルエリアコンピュータネットワーク（ＬＡＮ）５０及びワイドエリアコンピュータネットワーク（ＷＡＮ）を形成することができる。そのようなネットワークは、企業のコンピュータネットワーク及び社内ネットワークで利用され、それらはたいていにインターネットにアクセスすることができる。ＬＡＮ又はＷＡＮネットワークにおいて、パソコン２０は、ネットワークアダプタ又はネットワークインタフェース５１に交差するローカルエリアネットワーク５０に接続されている。ネットワークが用いられる時には、パソコン２０は、通信にインターネットなどのワイドエリアコンピュータネットワークを実現するために、モデム５４又は他のモジュールを使用することができる。内部又は外部の機器であるモデム５４は、シリアルポート４６によりシステムバス２３と接続される。かかるネットワーク接続は、単なる一例であり、ネットワークの正確な構成を示すものではない。すなわち、技術の通信モジュールによって、あるコンピュータから他のコンピュータへの接続を確立する他の方法もあることに留意されたし。

様々な実施形態において、ハードウェア、ソフトウェア、ファームウェア、又はこれらのあらゆる組み合わせにおいて、ここで説明されたシステム及びメソッドを実施し得る。ソフトウェアにおいて実装される場合は、メソッドは不揮発性コンピュータ可読メディアの１つ又は複数の指示又はコードとして保存され得る。コンピュータ可読メディアは、データストレージを含む。あくまでも例であり限定するものではないが、そのようなコンピュータ可読メディアは、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、フラッシュメモリ、若しくは他のタイプの電気、磁気、光学式の記憶媒体、又はその他のメディアであってもよい。すなわち、これらによって指示又はデータ構造体という形で、要求されたプログラムコードを運ぶか又は保存することができ、汎用コンピュータのプロセッサによってアクセスすることができる。

様々な実施形態で、本発明のシステム及びメソッドが、モジュールとして実装され得る。ここで用語「モジュール」は、実世界の機器、コンポーネント、又はハードウェアを用いて実装されたコンポーネント配置であり、例えばＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の、又は例えばモジュールの機能を実行するマイクロプロセッサーシステムや指示セットによる等、ハードウェアとソフトウェアの組み合わせとして実装され得る。これらは、実行中にマイクロプロセッサーシステムを特定の機器に変換する。モジュールは、ハードウェア単体により促進される一定の機能とハードウェア及びソフトウェアの組み合わせによって促進される他の機能という２つの組み合わせとして実施されてもよい。モジュールの少なくとも一部又は全部は、汎用コンピュータのプロセッサにおいて実行できる（図６において詳述したもの等）。したがって、各モジュールは様々な適当な構成で実現することができて、ここに例示した特定の実装に限られるものではない。

なお、実施形態の通常の機能のうちのすべてをここで開示しているわけではない。本発明の何れの実施形態を開発する場合においてでも、開発者の具体的な目標を達成するためには多くの実施に係る特別な決定が必要であり、これらの具体的な目標は実施形態及び開発者ごとに異なることに留意されたし。そのような開発努力は、複雑で時間を要するものであるが、本発明の利益を享受し得る当業者にとってはエンジニアリングの日常であると理解されたし。

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

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

Claims (18)

1. 機器のオペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセスを制御する方法であって、
   ハードウェアプロセッサによって、機械語のネイティブイメージを取得する工程と、
   前記ハードウェアプロセッサによって、前記ネイティブイメージが生成された親アセンブリを識別する工程と、
   前記ハードウェアプロセッサによって、前記親アセンブリの信頼カテゴリーを決定する工程と、
   前記親アセンブリの前記信頼カテゴリーに基づいて、前記ハードウェアプロセッサによって前記ネイティブイメージの前記信頼カテゴリーを決定する工程と、
   前記ハードウェアプロセッサによって、信頼カテゴリーが未信頼である前記ネイティブイメージのアクセスを機器のオペレーティング・システムのリソースに制限する工程と、
   を備える方法。
2. 前記ネイティブイメージの信頼カテゴリーが前記親アセンブリの信頼カテゴリーと対応する、請求項１に記載の方法。
3. 前記ネイティブイメージと前記親アセンブリの間の対応を決定する工程と、
   前記決定された対応に基づいて、前記ネイティブイメージが修正されたか否かを決定する工程と、
   を更に備える請求項１に記載の方法。
4. オペレーティング・システムのリソースに対する機械語のネイティブイメージのアクセスを制御する方法であって、
   ハードウェアプロセッサによって、書き込みアクセスを前記機械語の前記ネイティブイメージに制限する工程と、
   前記ハードウェアプロセッサによって、前記書き込みアクセスを制限された前記ネイティブイメージを作成するために使用した親アセンブリを識別する工程と、
   前記親アセンブリに基づき、前記ハードウェアプロセッサによって前記ネイティブイメージをアップデートする工程と、
   前記ハードウェアプロセッサによって、前記親アセンブリの信頼カテゴリーを決定する工程と、
   前記ハードウェアプロセッサによって、前記親アセンブリの信頼カテゴリーをアップデートされた前記ネイティブイメージに割り当てる工程と、
   前記ハードウェアプロセッサによって、前記信頼カテゴリーが未信頼である前記ネイティブイメージのアクセスを機器のオペレーティング・システムのリソースに制限する工程と、
   を備える方法。
5. 前記書き込みアクセスがｎｇｅｎ．ｅｘｅを除くすべての処理に制限される請求項４に記載の方法。
6. 前記機械語の前記ネイティブイメージのアップデートは、前記書き込みアクセスを制限された前記ネイティブイメージを前記親アセンブリの前記機械語の新しいネイティブイメージに交換する工程を含む、請求項４に記載の方法。
7. システムのオペレーティング・システムのリソースに機械語のネイティブイメージのアクセスを制御するためのシステムであって、
   ハードウェアプロセッサを備え、
   前記ハードウェアプロセッサは、
   前記機械語のネイティブイメージを取得し、
   前記ネイティブイメージが生成された親アセンブリを識別し、
   前記親アセンブリの信頼カテゴリーを決定し、
   前記親アセンブリの信頼カテゴリーに基づき、前記ネイティブイメージの信頼カテゴリーを決定し、
   前記信頼カテゴリーが未信頼であるネイティブイメージのアクセスを前記機器のオペレーティング・システムのリソースに制限するように構成される、
   システム。
8. 前記ネイティブイメージの信頼カテゴリーは、前記親アセンブリの信頼カテゴリーに対応する、請求項７に記載のシステム。
9. 前記プロセッサは、
   前記ネイティブイメージと前記親アセンブリとの対応を決定し、
   前記対応関係に基づいて前記ネイティブイメージが修正されたかどうかを決定するように構成される、
   請求項１に記載のシステム。
10. 機器のオペレーティング・システムのリソースに対して機械語のネイティブイメージのアクセスを制御するためのシステムであって、
    ハードウェアプロセッサを備え、
    前記ハードウェアプロセッサは、
    書き込みアクセスを機械語のネイティブイメージに制限し、
    前記書き込みアクセスを制限されたネイティブイメージを生成するために使用した親アセンブリを識別し、
    前記親アセンブリに基づき、前記ネイティブイメージをアップデートし、
    前記親アセンブリの信頼カテゴリーを決定し、
    前記親アセンブリの信頼カテゴリーを、アップデートされた前記ネイティブイメージに割り当て、
    前記信頼カテゴリーが未信頼であるアップデートされたネイティブイメージのアクセスを前記機器のオペレーティング・システムのリソースに制限するように構成される、
    システム。
11. 書き込みアクセスがｎｇｅｎ．ｅｘｅを除くすべての処理に制限される請求項１０に記載のシステム。
12. 前記機械語の前記ネイティブイメージのアップデートは、前記書き込みアクセスを制限された前記ネイティブイメージを前記親アセンブリの前記機械語の新しいネイティブイメージに交換する工程を含む、請求項１０に記載のシステム。
13. 機器のオペレーティング・システムのリソースに対して機械語のネイティブイメージのアクセスを制御するための不揮発性コンピュータ可読媒体であって、
    コンピュータに実行可能な指示を備え、
    前記指示は、
    機械語のネイティブイメージを取得し、
    ネイティブイメージが生成された親アセンブリを識別し、
    親アセンブリの信頼カテゴリーを決定し、
    前記親アセンブリの信頼カテゴリーに基づき、前記ネイティブイメージの信頼カテゴリーを決定し、
    信頼カテゴリーが未信頼であるネイティブイメージのアクセスを機器のオペレーティング・システムのリソースに制限する
    不揮発性コンピュータ可読媒体。
14. 前記ネイティブイメージの信頼カテゴリーは、前記親アセンブリの信頼カテゴリーに対応する、請求項１３に記載の不揮発性コンピュータ可読媒体。
15. ネイティブイメージと親アセンブリの間の対応を決定し、
    前記決定された対応に基づいて、ネイティブイメージが修正されたか否かを決定する、
    指示を更に備える請求項１３に記載の不揮発性コンピュータ可読媒体。
16. 機器のオペレーティング・システムのリソースに対して機械語のネイティブイメージのアクセスを制御するための不揮発性コンピュータ可読媒体であって、
    コンピュータに実行可能な指示を備え、
    前記指示は、
    書き込みアクセスを前記機械語の前記ネイティブイメージに制限し、
    前記書き込みアクセスを制限された前記ネイティブイメージを生成するために使用した親アセンブリを識別し、
    前記親アセンブリに基づき、前記ネイティブイメージをアップデートし、
    前記親アセンブリの信頼カテゴリーを決定し、
    前記親アセンブリの信頼カテゴリーを、アップデートされた前記ネイティブイメージに割り当て、
    前記信頼カテゴリーが未信頼であるアップデートされた前記ネイティブイメージのアクセスを前記機器のオペレーティング・システムのリソースに制限する、
    不揮発性コンピュータ可読媒体。
17. 前記書き込みアクセスがｎｇｅｎ．ｅｘｅを除くすべての処理に制限される請求項１６に記載の不揮発性コンピュータ可読媒体。
18. 前記機械語の前記ネイティブイメージのアップデートは、前記書き込みアクセスを制限された前記ネイティブイメージを前記親アセンブリの前記機械語の新しいネイティブイメージに交換する、請求項１８に記載の不揮発性コンピュータ可読媒体。