JPWO2014098239A1

JPWO2014098239A1 - 監視装置および監視方法

Info

Publication number: JPWO2014098239A1
Application number: JP2014553231A
Authority: JP
Inventors: 満昭秋山; 剛男針生
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-12-21
Filing date: 2013-12-20
Publication date: 2017-01-12
Anticipated expiration: 2033-12-20
Also published as: CN104871173A; EP2937807A4; EP2937807A1; WO2014098239A1; EP2937807B1; JP6005761B2; US9600665B2; US20150332045A1; CN104871173B

Abstract

監視システムにおける監視部（１０）は、実行するプログラムが監視対象のプログラムであるか否かを判定する。そして、監視システムにおける監視部（１０）は、実行するプログラムが監視対象のプログラムであると判定された場合には、該監視対象のプログラムによって呼び出される関数に含まれる命令列の前に、所定の条件を満たす命令列と、所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する。

Description

本発明は、監視装置および監視方法に関する。

従来、コンピュータシステム上において、攻撃者からの不正侵入や悪意のあるプログラムが動作している事を検知するために、システムの挙動から不審な動作を検知するホスト型侵入検知手法が提案されている（例えば、非特許文献１参照）。

システム上のアプリケーションの動作を監視する方法として、ＡＰＩ（Application Program Interface）呼び出しを監視する方法が行われている。このＡＰＩとは、各種システムコールを抽象化している関数である。例えば、アプリケーションは、ＡＰＩを通じて、直接ハードウェアを意識することなく簡略的にファイル入出力や通信制御等を行うことができる。このようなＡＰＩ呼び出しを監視することによって、ＡＰＩの種類やどのような引数を入力したか等のログ情報が取得でき、その結果、アプリケーションの一連の動作を監視することができる。

また、このようなログ情報を取得する方法として、ＡＰＩ呼び出しもしくはＡＰＩの実行途中に制御フローを遷移させてログ情報を取得させるＡＰＩフックが利用されている。例えば、ＡＰＩフックによってログ情報を取得する方法として、各ＡＰＩの先頭命令にジャンプ命令やコール命令を挿入して、別の命令列へ処理フローを遷移させ、ログ情報の取得を行い、元のＡＰＩに処理フローを戻す方法が知られている。

"Detours: Binary Interception of Win32 Functions"、3rd USENIX Windows（登録商標） NT Symposium、USENIX、Galen Hunt著、July 1999

しかしながら、上記した従来の技術では、ＡＰＩフックを利用するために、先頭命令にジャンプ命令やコール命令を挿入するため、悪性プログラムが、本来の悪性動作をしなくなってしまい、ＡＰＩ呼び出しを適切に監視することができない場合がある。

例えば、上記したＡＰＩフックを利用する方法では、ＡＰＩの先頭命令にジャンプ命令やコール命令を挿入することで、別の命令列へ処理フローを遷移させるので、悪性プログラムがＡＰＩの先頭命令を確認することでＡＰＩがフックされているかどうかを判別できてしまう。このため、悪性プログラムは、ＡＰＩがフックされていると判断した場合には、本来の悪性動作をしなくなってしまい、ＡＰＩ呼び出しを適切に監視することができない可能性がある。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、ＡＰＩ呼び出しを監視していることが悪性プログラム側で分からないようにし、ＡＰＩ呼び出しを適切に監視することを目的とする。

上述した課題を解決し、目的を達成するため、監視装置は、実行するプログラムが監視対象のプログラムであるか否かを判定する判定部と、前記判定部によって実行するプログラムが監視対象のプログラムであると判定された場合には、該監視対象のプログラムによって呼び出される関数に含まれる命令列の前に、所定の条件を満たす第１命令列と、前記所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する命令付与部と、を備えたことを特徴とする。

また、監視方法は、実行するプログラムが監視対象のプログラムであるか否かを判定する判定工程と、前記判定工程によって実行するプログラムが監視対象のプログラムであると判定された場合には、該監視対象のプログラムによって呼び出される関数に含まれる命令列の前に、所定の条件を満たす第１命令列と、前記所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する命令付与工程と、を含んだことを特徴とする。

本願に開示する監視装置および監視方法は、ＡＰＩ呼び出しを監視していることが悪性なプログラム側で分からないようにし、ＡＰＩ呼び出しを適切に監視することが可能である。

図１は、第一の実施の形態に係る監視システムの構成を示すブロック図である。図２は、監視部の構成を示す機能ブロック図である。図３は、通常時のＡＰＩの実行手順を説明する図である。図４は、通常時のＡＰＩ呼び出しを説明する図である。図５は、ＡＰＩフックについて説明する図である。図６は、ＡＰＩの先頭命令を、条件分岐命令と条件分岐命令の条件を常に満たす命令列とに書き換えた場合の処理を説明する図である。図７は、ＡＰＩフック時のＡＰＩの実行手順を説明する図である。図８は、第一の実施の形態に係る監視部の処理動作を示すフローチャートである。図９は、監視プログラムを実行するコンピュータを示す図である。

以下に添付図面を参照して、この発明に係る監視装置および監視方法の好適な実施形態を詳細に説明する。なお、この実施形態によりこの発明が限定されるものではない。

［第一の実施の形態］
まず、図１を用いて、第一の実施の形態に係る監視システムの概要について説明する。図１は、本実施例に係る監視システムの構成を示すブロック図である。同図に示すように、本実施例に係る監視システムは、監視部１０と、監視対象プログラム２０と、監視対象外プログラム２０ａと、ＯＳ（Operating System）３０とを有する。なお、ここで説明する構成はあくまで一例であり、監視システムは他のさまざまな形態でも実施が可能である。

監視部１０は、ＯＳ３０上で動作するプログラムであり、監視対象プログラム２０からホスト資源やプロセスに関するアクセスを監視する。例えば、この監視部１０は、複数のモジュールから構成されるモジュールライブラリとして実装される。各監視部１０は、プロセス単位（プログラム単位）またはモジュール単位で、監視対象プログラム２０の動作を監視する。

監視対象プログラム２０は、監視システムによる監視の対象となるプログラムであり、監視部１０と一緒に動作する。例えば、この監視対象プログラム２０は、コンピュータウィルスやワームなどの悪性プログラムや、脆弱性を有する可能性がある信頼できないプログラムなどである。

第一の実施の形態に係る監視システムにおいては、監視対象プログラム２０によって呼び出されるＡＰＩ（Application Programming Interface）の先頭命令が、条件分岐命令と条件分岐命令の前にその条件分岐命令を常に満たす命令列とを付与したフック用命令列に置換される。

また、監視対象外プログラム２０ａは、監視システムによる監視の対象外となるプログラムである。なお、監視部１０は、監視対象外プログラム２０ａとなる悪性プログラムの特徴を事前に把握しているものとし、監視対象プログラム２０と監視対象外プログラム２０ａとを判別できるものとする。

ＯＳ３０は、各種プログラムを動作させるためのソフトウェアであり、システムコールにより呼び出された各種機能を監視対象プログラム２０または監視対象外プログラム２０ａに提供する。

第一の実施の形態に係る監視システムの監視部１０では、監視対象プログラム２０を実行すると判定した場合には、フック対象のＡＰＩをフックする「hook_API」を監視対象プログラム２０に挿入する。そして、この監視対象プログラム２０がフックされたＡＰＩを実行すると、フックＡＰＩを経由してシステムコールを実行するため、監視部１０は、監視対象プログラム２０のＡＰＩ実行をすべて監視することができる。

つまり、監視対象プログラム２０がフックされたＡＰＩを実行してフックＡＰＩを経由することで、監視対象プログラム２０の挙動を監視する処理（例えば、ＡＰＩの入力値等のログ情報を取得する処理）を行う結果、監視対象プログラム２０のＡＰＩ実行を監視することが可能となる。

次に、図２を用いて、監視部１０の構成について説明する。図２は、監視部１０の構成を示す機能ブロック図である。図２に示すように、監視部１０は、特に、プログラム実行部１１と、判定部１２と、ＤＬＬ（Dynamic Link Library）監視部１３と、ＤＬＬ読込制御部１４と、命令付与部１５とを有する。なお、ここでは、各機能部が有する機能の概要について説明し、各機能部によって行われる処理については、後に詳細に説明する。

プログラム実行部１１は、監視対象プログラム２０または監視対象外プログラム２０ａを動作させる。まず、監視対象外プログラム２０ａを実行する場合の通常の処理について、図３を用いて説明する。図３は、通常時のＡＰＩの実行手順を説明する図である。図３に例示するように、監視対象外プログラム２０ａがAPI_1Aを利用する場合には、API_1Aが実装されているDLL_1をプログラムが動作しているプロセスのメモリ上に読み込む。そして、監視対象外プログラム２０ａが、DLL_1で定義されているAPI_1Aを実行する。

また、プログラム実行部１１は、監視対象プログラム２０を動作させる場合には、hook_API」を呼び出すためのＡＰＩが記述されたコードが監視対象プログラム２０に挿入されたうえで、監視対象プログラム２０を実行させる。具体的には、プログラム実行部１１は、監視対象プログラム２０を動作させる場合には、「hook_API」を呼び出すためのＡＰＩが記述されたコードが監視対象プログラム２０に挿入され、そのうえで、監視システムが提供する半透過的な仮想隔離環境で監視対象プログラム２０を実行させる。

このように、プログラム実行部１１は、「hook_API」を呼び出すためのＡＰＩが記述されたコードが監視対象プログラム２０に挿入された後に、監視対象プログラム２０を実行することで、監視対象プログラム２０の挙動を監視する処理（例えば、ＡＰＩの入力値等のログ情報を取得する処理）を行い、監視対象プログラム２０のＡＰＩ実行を監視する。

判定部１２は、実行するプログラムが監視対象のプログラムであるか否かを判定する。具体的には、判定部１２は、プログラム実行部１１によって実行されるプログラムが監視対象プログラム２０であるか監視対象外プログラム２０ａであるかを判定し、判定の結果をＤＬＬ監視部１３に通知する。

ＤＬＬ監視部１３は、フック対象ＡＰＩを実装するＤＬＬがロードされたか否かを監視する。具体的には、ＤＬＬ監視部１３は、判定部１２から監視対象プログラム２０が実行する旨の判定結果を受け付けると、フック対象ＡＰＩを実装するＤＬＬが、監視対象プログラム２０が動作するプロセスのメモリに読み込まれたかどうかを監視する。そして、ＤＬＬ監視部１３は、フック対象ＡＰＩを実装するＤＬＬがメモリに読み込まれた場合には、読み込まれたことをＤＬＬ読込制御部１４に通知する。

ＤＬＬ読込制御部１４は、フックＤＬＬを対象プログラムのプロセスメモリにロードする。具体的には、ＤＬＬ読込制御部１４は、ＤＬＬ監視部１３からフック対象ＡＰＩを実装するＤＬＬがメモリに読み込まれた旨の通知を受け付けた場合には、フックＡＰＩを実装するＤＬＬを対象のプロセスのメモリに読み込ませる。

命令付与部１５は、監視対象プログラム２０が実行される際に、該監視対象プログラム２０によって呼び出されるＡＰＩに含まれる命令列の前に、所定の条件を満たす命令列と、所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する。

具体的には、命令付与部１５は、ＤＬＬ読込制御部１４によってフックＡＰＩを実装するＤＬＬが対象のプロセスのメモリに読み込まれた場合には、ＤＬＬの初期化処理としてフック対象のＡＰＩの先頭周辺命令を、所定の条件を常に満たす算術演算や比較などの命令列と、所定の条件を満たした場合に、監視対象プログラム２０の挙動を監視する処理（例えば、ログ情報等を取得する処理）を実行する制御フローに遷移させる条件分岐命令とに書き換える。

例えば、所定の条件を常に満たす命令列と、所定の条件を満たした場合にログ情報等を取得する制御フローに遷移させる条件分岐命令を対応付けた組が予め複数設定されており、命令付与部１５は、複数の組から一つの組をランダムに取得し、取得した組で対応付けられた条件分岐命令と命令列とを、監視対象プログラム２０によって呼び出されるＡＰＩ先頭命令に付与するようにしてもよい。また、命令付与部１５は、所定の条件を常に満たす命令列と、所定の条件を満たした場合にログ情報等を取得する制御フローに遷移させる条件分岐命令とを生成するようにしてもよい。

ここで、図４を用いて、通常のＡＰＩ呼び出しについて説明する。図４は、通常時のＡＰＩ呼び出しを説明する図である。図４に例示するように、監視対象プログラムに含まれるＡＰＩの呼び出しが行われると、ＡＰＩの内部処理を実行する。

そして、このようなＡＰＩの先頭命令を書き換えることで、別の命令列へ処理を遷移させ、ログ取得等を行うＡＰＩフックによるＡＰＩ呼び出し監視方法が用いられている。例えば、図５に示すように、ＡＰＩの先頭命令にフック関数の呼び出し命令を付与することで、ＡＰＩの入力値等のログを取得する処理フローへ遷移し、その後、元のＡＰＩに処理フローを戻す。

ここで、従来では、フック関数の呼び出し命令として、ＡＰＩの先頭命令がジャンプ命令やコール命令に書き換えられていた。これに対して、本実施形態に係る監視部１０では、フック関数の呼び出し命令として、ＡＰＩの先頭命令を、条件分岐命令と、条件分岐命令を常に満たす算術演算や比較などの命令列とに書き換える。

例えば、条件分岐命令は、フラグレジスタの状態に応じて、指定されたアドレスに制御フローを遷移させるかどうかを決定する命令であるものとする。ここで、フラグレジスタとは、算術演算や比較などの命令の結果として「０」や「１」が格納されているレジスタである。また、上記の命令列は、条件分岐命令の条件を満たす算術演算や比較などの命令列である。この命令列によって算術演算や比較の処理が実行されると、フラグレジスタの状態が常に条件分岐命令の条件を満たす状態となるようになっているものとする。

つまり、ＡＰＩの先頭命令を、条件分岐命令とその条件分岐命令の条件を常に満たす算術演算や比較などの命令列とに書き換えることで、必ず指定したアドレスに制御フローが遷移するジャンプ命令と同義の命令列を生成できる。この条件分岐命令とその条件分岐命令を常に満たす命令列との組み合わせは、無数の組み合わせを生成することが可能であり、プログラム側から推測不可能な命令列にすることが可能であり、フックされているかどうかの判別を困難にすることが可能である。

つまり、監視部１０は、制御フローの遷移はジャンプ命令やコール命令の代わりに、条件分岐命令と条件分岐命令の条件を常に満たす命令列を付与することで、ＡＰＩの呼び出し元のプログラムにＡＰＩはフックされていないと判断させることができ、ＡＰＩを実行させるように仕向けることができるため、ＡＰＩ呼び出しを監視していることが悪性プログラム側で分からないようにし、ＡＰＩ呼び出しを適切に監視することができる。

さらに、ＡＰＩをフックする際に毎回動的に命令列を生成することも可能である。このため、ＡＰＩ呼び出し元のプログラムからは、ＡＰＩの先頭と特定の命令列のパターンとの比較によりフックされているかどうかを判断することができない。これにより、悪性プログラムにばれることなくＡＰＩフックを行い、プログラムの動作を監視することができる。

ここで、図６の例を用いて、ＡＰＩの先頭命令を、条件分岐命令と条件分岐命令の条件を常に満たす命令列とに書き換えた場合について説明する。図６は、ＡＰＩの先頭命令を、条件分岐命令と条件分岐命令の条件を常に満たす命令列とに書き換えた場合の処理を説明する図である。図６に例示するように、監視対象プログラム２０によって呼びされるAPI_Aの先頭命令を、フラグレジスタ調整用コードと条件分岐命令とに書き換える。ここで、フラグレジスタ調整用コードとは、算術演算や比較などを行う命令列であり、この命令列によって算術演算や比較の処理が実行されると、フラグレジスタの状態が条件分岐命令の条件を満たす状態となるように調整させる命令コードである。

また、条件分岐命令とは、フラグレジスタの状態が、所定の条件を満たす場合に、指定されたアドレスに制御フローを遷移させる命令であるものとする。上記したように、条件分岐命令の前に付与されたフラグレジスタ調整用コードは、フラグレジスタの状態が所定の条件を満たす状態となるように調整するので、指定されたアドレスに制御フローを遷移させることができる。この制御フローとは、例えば、API_Aの入力値等のログを取得する処理を行う制御フローである。

また、ＡＰＩの先頭は、条件分岐命令と条件分岐命令の条件を常に満たす命令列とに書き換えられるので、元のＡＰＩに制御フローを戻す前に、上書きされたオリジナルの処理を実行した後に、元のＡＰＩに制御フローに戻って、上書きされていないオリジナル処理、すなわちＡＰＩの内部処理を行う。これにより、矛盾無くＡＰＩを実行できる。

次に、図７を用いて、ＡＰＩの実行手順を説明する。監視対象プログラム２０（図７では、「プログラム」と記載）が実行されると、該監視対象プログラム２０が、API_1Aが実装されているDLL_1を読み込む（図７の「１」参照）。そして、監視対象プログラム２０は、DLL_1がロードされた後に、API_1Aをフックして処理を行うhook_API_1Aが実装されているDLL_1_hookを読み込む（図７の「２」参照）。

ここで、監視部１０は、DLL_1_hookが監視対象プログラム２０によって読み込まれると、API_1Aを実行した場合においてhook_API_1Aへ命令が遷移するように、API_1Aの先頭命令列に、条件分岐命令とその条件分岐命令の前に条件分岐命令の条件を常に満たす命令列とを付与する。その後、監視対象プログラム２０が、DLL_1で定義されているAPI_1Aを実行すると、フック処理が実行されたのちに、ＡＰＩが実行される（図７の「３」参照）。

このように、監視部１０は、DLL_1_hookが監視対象プログラム２０によって読み込まれた際に、API_1Aを実行した場合に、hook_API_1Aへ命令が遷移するようにAPI_1Aの先頭命令列に、条件分岐命令とその条件分岐命令を常に満たす命令列とを付与している。なお、DLL_1のファイル自体をあらかじめ書き換えておくことも考えられるが、ソースコードを修正してコンパイルしなければならないため、フック対象のＡＰＩを実装するＤＬＬのソースコードが公開されている必要がある。また、バイナリ自体を直接書き換えることも技術的には可能であるが、バイナリのリバースエンジニアリングが必要になり、プログラムによっては禁じられているものもあり、書き換えることができない場合がある。

［監視部による処理］
次に、図８を用いて、第一の実施の形態に係る監視部１０による処理を説明する。図８は、第一の実施の形態に係る監視部の処理動作を示すフローチャートである。

図８に示すように、監視部１０の判定部１２は、監視対象プログラムが実行されたか否かを判定し（ステップＳ１０１）、監視対象プログラムが実行されたと判定された場合には（ステップＳ１０１肯定）、フック対象ＡＰＩを実装するＤＬＬがロードされたか否かを判定する（ステップＳ１０２）。

この結果、監視部１０のＤＬＬ監視部１３は、フック対象ＡＰＩを実装するＤＬＬがロードされていないと判定した場合には（ステップＳ１０２否定）、ステップＳ１０２の処理に戻る。また、フック対象ＡＰＩを実装するＤＬＬがロードされたと判定した場合には（ステップＳ１０２肯定）、監視部１０のＤＬＬ読込制御部１４は、フックＤＬＬを対象プログラムのプロセスメモリにロードする（ステップＳ１０３）。

そして、監視部１０の命令付与部１５は、フック対象ＡＰＩに対して先頭命令をフックＡＰＩへ遷移するように書き換える（ステップＳ１０４）。具体的には、命令付与部１５は、ＤＬＬ読込制御部１４によってフックＡＰＩを実装するＤＬＬを対象のプロセスのメモリに読み込まれると、ＤＬＬの初期化処理としてフック対象のＡＰＩに対して先頭周辺命令を、条件分岐命令と、条件分岐命令の条件を常に満たす算術演算や比較などの命令列とに書き換える。

そして、監視部１０は、全てのフック対象ＡＰＩをフックしたかを判定する（ステップＳ１０５）。つまり、フック対象ＡＰＩは、複数のＤＬＬで実装されている場合もあるし、ＤＬＬの読み込みタイミングがプログラムの起動時であるとは限らないため、フック対象ＡＰＩがすべてフックできるまで、監視対象プログラムを監視する必要がある。

この結果、監視部１０は、全てのフック対象ＡＰＩをフックしていないと判定した場合には（ステップＳ１０５否定）、ステップＳ１０２の処理に戻る。また、監視部１０は、全てのフック対象ＡＰＩをフックしたと判定した場合には（ステップＳ１０５肯定）、処理を終了する。

[第一の実施形態の効果]
上述してきたように、第一の実施形態にかかる監視部１０は、実行するプログラムが監視対象のプログラムであるか否かを判定する。そして、監視部１０は、実行するプログラムが監視対象のプログラムであると判定された場合には、該監視対象のプログラムによって呼び出される関数に含まれる命令列の前に、所定の条件を満たす命令列と、所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する。

このため、第一の実施形態にかかる監視部１０は、制御フローを遷移させるための命令列と、条件分岐命令のパターンを無数に生成することができるため、監視対象プログラム２０側からＡＰＩがフックされていることが判別困難であるため、プログラムの動作監視を阻害されることなく、監視対象プログラム２０の動作を監視できる。このように、監視部１０では、ＡＰＩ呼び出しを監視していることが悪性プログラム側で分からないようにし、ＡＰＩ呼び出しを適切に監視することが可能となる。

また、第一の実施形態にかかる監視部１０は、所定の条件を常に満たす命令列と、所定の条件を満たした場合にログ情報等を取得する制御フローに遷移させる条件分岐命令とを対応付けた複数の組から、一つの組をランダムに取得し、取得した組で対応付けられた条件分岐命令と命令列とを、監視対象プログラム２０によって呼び出されるＡＰＩ先頭命令に付与する。このため、制御フローを遷移させるための命令列と、条件分岐命令の組み合わせを予め複数生成しておくことができるため、ＡＰＩの先頭命令に、所定の条件を満たす命令列と、所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを付与することが容易となる。また、ランダムに取得するため、監視対象プログラム２０側からＡＰＩがフックされていることが判別困難であるようにすることができる。

また、第一の実施形態にかかる監視部１０は、フラグレジスタに格納される値が所定の条件を満たすように演算または比較を行う第１命令列と、フラグレジスタが所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する。このため、既存のフラグレジスタを利用して、制御フローを遷移させるための命令列と、条件分岐命令とのパターンを無数に生成することが可能となる。

また、第一の実施形態にかかる監視部１０は、条件分岐命令と命令列とを含むＡＰＩを実行し、制御処理として、監視対象プログラム２０の挙動を監視する処理を行う。例えば、監視部１０は、ＡＰＩの入力値等のログを取得することで、監視対象プログラム２０の挙動を監視することができ、監視対象プログラムの動作を適切に監視することが可能である。

また、カーネルレイヤでのシステムコール監視を行った場合には、監視対象プログラムだけでなく無関係なプログラムも含めたＯＳ上の全てのシステムコールイベントをトラップし、その中から監視対象のプログラムかどうかをプロセスＩＤ等から判別して処理する必要がある。このため、カーネルレイヤでのシステムコール監視は、無関係なシステムコールイベントを処理するためのオーバーヘッドが発生する。一方で、第一の実施形態にかかる監視部１０は、監視対象プログラム２０に対してのみ監視を行うため、前述のオーバーヘッドが発生しない。

［第二の実施形態］
さて、これまで本発明の実施例について説明したが、本発明は上述した実施形態以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では第二の実施形態として本発明に含まれる他の実施形態を説明する。

（１）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、判定部１２と命令付与部１５とを統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

（２）プログラム
また、上記実施形態において説明した監視部１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、監視部１０が実行する処理をコンピュータが実行可能な言語で記述した監視プログラムを作成することもできる。この場合、コンピュータが監視プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる監視プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された監視プログラムをコンピュータに読み込ませて実行することにより上記第一の実施形態と同様の処理を実現してもよい。以下に、図２に示した監視部１０と同様の機能を実現する監視プログラムを実行するコンピュータの一例を説明する。

図９は、監視プログラムを実行するコンピュータ１０００を示す図である。図９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図９に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図９に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図９に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図９に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図９に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の監視プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、アクセス監視手順、アクセス制御手順、プロセス監視手順、プロセス制御手順を実行する。

なお、監視プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、監視プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１０監視部
１１プログラム実行部
１２判定部
１３ＤＬＬ監視部
１４ＤＬＬ読込制御部
１５命令付与部
２０監視対象プログラム
２０ａ監視対象外プログラム
３０ＯＳ

Claims

実行するプログラムが監視対象のプログラムであるか否かを判定する判定部と、
前記判定部によって実行するプログラムが監視対象のプログラムであると判定された場合には、該監視対象のプログラムによって呼び出される関数に含まれる命令列の前に、所定の条件を満たす第１命令列と、前記所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する命令付与部と、
を備えたことを特徴とする監視装置。
前記命令付与部は、前記条件分岐命令と前記第１命令列とを対応付けた複数の組から一つの組をランダムに取得し、取得した組で対応付けられた条件分岐命令と前記第１命令列とを、前記監視対象のプログラムによって呼び出される命令列の前に付与することを特徴とする請求項１に記載の監視装置。
前記命令付与部は、フラグレジスタに格納される値が前記所定の条件を満たすように演算または比較を行う第１命令列と、前記フラグレジスタが所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与することを特徴とする請求項１または２に記載の監視装置。
前記命令付与部によって条件分岐命令と前記第１命令列とが付与された命令列を含む前記関数を実行し、前記所定の制御処理として、前記監視対象のプログラムの挙動を監視する処理を行う実行部をさらに備えることを特徴とする請求項１または２に記載の監視装置。
前記命令付与部によって条件分岐命令と前記第１命令列とが付与された命令列を含む前記関数を実行し、前記所定の制御処理として、前記監視対象のプログラムの挙動を監視する処理を行う実行部をさらに備えることを特徴とする請求項３に記載の監視装置。
監視装置で実行される監視方法であって、
実行するプログラムが監視対象のプログラムであるか否かを判定する判定工程と、
前記判定工程によって実行するプログラムが監視対象のプログラムであると判定された場合には、該監視対象のプログラムによって呼び出される関数に含まれる命令列の前に、所定の条件を満たす第１命令列と、前記所定の条件を満たした場合に所定の制御処理を開始する命令である条件分岐命令とを順に付与する命令付与工程と、
を含んだことを特徴とする監視方法。