JP2015130008A - 動態解析方法及び動態解析装置 - Google Patents

Abstract

【課題】 本発明の課題は、通信に係る処理を含むプログラムの動態解析における観測時間を短縮することを目的とする。
【解決手段】 上記課題は、コンピュータによって実行される動態解析方法であって、プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶し、前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を設定し、前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行することにより達成される。
【選択図】 図３

Description

本発明は、プログラムの動態解析に関する。

近年、スピア型と呼ばれるマルウエアが増加してきている。スピア型と呼ばれるマルウエアは、特定ユーザ向けのカスタマイズしたプログラムであるため、アンチウイルスのパターンで検出できないことが多い。そこで、マルウエアをエミュレータやＶＭ（Virtual Machine）上等での環境で実際動かして解析する動態解析（シミュレーション）が行われている。

動態解析の時間を制御する観点において、プラント制御装置の全体のタイムスケールを決定する基準時間を可変とすることにより、プラント制御アプリケーションそのものを変更することなしに、シミュレーションを加速又は減速して実施できる技術が知られている。

特開２０１０−２６２８９１号公報

上述したプラント制御では、プラントの反応（プロセスＩＯ）の部分の時間は、外部ＩＯ時間であり応答時間は可変である。同期が確立できれば、単純に制御プログラムの実行速度とパラメタとを変更して加減速することで、動態解析の観測時間を調整することができる。このような、基準時間を可変としてタイマの運針が変化するプラント制御では、以下の問題がある。

第１に、Ｉ／Ｏが通信に関わる処理の場合、タイマの運針を変化させるだけでは、通信のタイムアウト待ち時間が変化して通信が正常に行われない場合がある。第２に、通信が処理の多くを占めるマルウエアでは、タイマの運針を高速化するだけでは、動態解析全体の観測時間を短縮させることが困難である。

従って、１つの側面では、本発明は、通信に係る処理を含むプログラムの動態解析における観測時間を短縮することである。

本実施例の一態様によれば、コンピュータによって実行される動態解析方法であって、プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶し、前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を設定し、前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する。

また、上記課題を解決するための手段として、コンピュータに上記処理を実行させるためのプログラム、及び動態解析装置とすることもできる。

本実施例の一態様によれば、通信に係る処理を含むプログラムの動態解析における観測時間を短縮できる。

本実施例における動態解析システムのネットワーク構成例を示す図である。 動態解析サーバのハードウェア構成を示す図である。 動態解析サーバの機能構成例を示す図である。 通信系のＡＰＩを呼び出した場合を説明するための図である。 計時関係のＡＰＩを呼び出した場合を説明するための図である。 スチールＡＰＩ選択ＤＢのデータ構成例を示す図である。 各種テーブルのデータ構成例を示す図である。 動態解析処理を説明するための図（その１）である。 動態解析処理を説明するための図（その２）である。 ２倍速の場合を説明するための図である。 ＯＳカーネルのＡＰＩの呼び出し例を示す図である。 ２倍速の場合のソフトウェア割込処理を説明するためのフローチャート図である。 ２倍速の場合の時刻取得処理を説明するためのフローチャート図である。 ２倍速の場合の通信ＡＰＩ処理を説明するためのフローチャート図である。 ２倍速の場合の観測時間の比較例を示す図である。 １／２倍の場合を説明するための図である。 １／２倍速の場合のソフトウェア割込処理を説明するためのフローチャート図である。 １／２倍速の場合の時刻取得処理を説明するためのフローチャート図である。 １／２倍速の場合の通信ＡＰＩ処理を説明するためのフローチャート図である。 １／２倍速の場合の観測時間の比較例を示す図である。 マルウエアによる探索処理に関する比較例を示す図である。 ２倍速の場合における通信異常回避を説明するための図である。 １／２倍速の場合における通信異常回避を説明するための図である。 マルウェアの処理フェーズにおける本実施例の効果を説明するための図である。 実行速度の設定画面の例を示す図である。

以下、本発明の実施の形態を図面に基づいて説明する。本実施例に係る動態解析は、プログラムの動作を検証する動作シミュレーションに相当し、コンピュータウイルス、ワーム等のマルウエアを解析する。

本実施例に係る動態解析は、以下のことを前提とする。
・特定の観測プロセスにのみ適用されるサンドボックス環境において行われるシミュレーションであり、システム全体の速度を加減速するものではない。
・外部Ｉ／Ｏは、非同期のＴＣＰ／ＩＰ通信であり、基本的に速度を可変にできないＩ／Ｏである。

図１は、本実施例における動態解析システムのネットワーク構成例を示す図である。図１において、動態解析システム１０００は、制御端末３と、動態サーバ１００と、種々のホスト５１、５２等と、ルータ６とを有する。動態解析サーバ１００と、種々のホスト５１、５２等と、ルータ６は、ネットワーク４に接続される。また、図示しない外部ネットワークへは、ルータ６を介して接続される。

制御端末３は、回線２によって動態解析サーバ１００に接続され、動態解析サーバ１００を制御する。制御端末３は、解析のターゲットプログラムであるマルウエア９の動態解析を動態解析サーバ１００で実行するために、ユーザによって使用される。

動態解析サーバ１００は、情報処理装置であり、ＯＳ（Operating System）カーネル７、上にサンドボックス環境８を備える。サンドボックス環境８において、マルウエア９を動作させ、動態解析が行われる。

ホスト５１、５２等は、動態解析サーバ１００が属するネットワーク４に存在するＤＮＳ（Domain Name System）サーバ、Ｗｅｂサーバ、ＩＲＣ（Internet Relay Chat）サーバ（Ｃ＆Ｃサーバ）等である。本実施例において、ホスト５１のＩＰアドレスは「192.163.0.11」とし、ホスト５２のＩＰアドレスは「192.163.0.12」とする。

ルータ６は、外部ネットワークと接続し、異なるネットワークへの中継を行う通信装置である。ルータ６は、データの中継先の宛先サーバが存在しない場合、通信エラーをネットワーク４の送信元に返す。

動態解析サーバ１００は、図２に示すようなハードウェア構成を有する。図２は、動態解析サーバのハードウェア構成を示す図である。図２において、動態解析サーバ１００は、コンピュータによって制御される端末であって、ＣＰＵ（Central Processing Unit）１１と、主記憶装置１２と、補助記憶装置１３と、入力装置１４と、表示装置１５と、通信Ｉ／Ｆ（インタフェース）１７と、ドライブ装置１８とを有し、バスＢに接続される。

ＣＰＵ１１は、主記憶装置１２に格納されたプログラムに従って動態解析サーバ１００を制御する。主記憶装置１２には、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１にて実行されるプログラム、ＣＰＵ１１での処理に必要なデータ、ＣＰＵ１１での処理にて得られたデータ等を記憶又は一時保存する。

補助記憶装置１３には、ＨＤＤ（Hard Disk Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１３に格納されているプログラムの一部が主記憶装置１２にロードされ、ＣＰＵ１１に実行されることによって、各種処理が実現される。記憶部１３０は、主記憶装置１２及び／又は補助記憶装置１３を有する。

入力装置１４は、マウス、キーボード等を有し、ユーザが動態解析サーバによる処理に必要な各種情報を入力するために用いられる。表示装置１５は、ＣＰＵ１１の制御のもとに必要な各種情報を表示する。通信Ｉ／Ｆ１７は、有線又は無線などのネットワークを通じて通信を行う。通信Ｉ／Ｆ１７による通信は無線又は有線に限定されるものではない。
動態解析サーバ１００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９によって動態解析サーバに提供される。

ドライブ装置１８は、ドライブ装置１８にセットされた記憶媒体１９（例えば、ＣＤ−ＲＯＭ等）と動態解析サーバ１００とのインタフェースを行う。

また、記憶媒体１９に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体１９に格納されたプログラムは、ドライブ装置１８を介して動態解析サーバ１００にインストールされる。インストールされたプログラムは、動態解析サーバ１００により実行可能となる。

尚、プログラムを格納する媒体としてＣＤ−ＲＯＭに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。

図３は、動態解析サーバの機能構成例を示す図である。図３において、動態解析サーバ１００は、主な処理部として、ＯＳカーネル７ｋと、サンドボックス環境８と、マルウエア９と、ＡＰＩ（Application Program Interface）制御部４１と、計時調整指示部６１と、サンドボックス実行ランチャー９１とを有する。また、記憶部１３０には、スチールＡＰＩ選択データベース（ＤＢ）３１が記憶されている。

サンドボックス実行ランチャー９１は、ユーザがマルウエア９の動態解析に係る操作を容易に行うためのアプリケーションである。

ＡＰＩ制御部４１は、更に、通信宛先管理部４２を有する。通信宛先管理部４２は、マルウエア９からの通信ＡＰＩの呼び出しに対して、通信宛先がネットワーク４上の存在有無に応じた処理を行う。また、通信宛先管理部４２は、記憶部１３０内の通信宛先管理部４２に割り当てられた記憶領域に通信管理テーブル４２ａとノード管理テーブル４２ｂとを有する。

通信管理テーブル４２ａは、ファイルディスクリプタ（ｆｄ）毎に通信状態を管理するテーブルである。ノード管理テーブル４２ｂは、ネットワーク４に実在するホストのＩＰアドレスを管理するテーブルである。通信宛先管理部４２は、通信管理テーブル４２ａを用いて、通信状態を管理した後、ノード管理テーブル４２ｂを参照して、通信宛先がネットワーク４上に存在するか否かを判断する。

通信宛先がネットワーク４に存在しない場合、通信宛先管理部４２は、通信を抑止し、ルータ６に代わってマルウエア９へ通信エラーを返す処理を行う。この処理によって、マルウエア９による探索パケットの送信に対して、存在しないホスト（以下、「ノード」とも言う）への探索時間を省略するため、通信が処理の多くを示すマルウエア９の動態解析に要する時間を短縮することができる。

通信宛先がネットワーク４に存在する場合、通信宛先管理部４２は、通信管理テーブル４２ａを参照して通信中を判断した場合、通信中通知をサンドボックス環境８に対して行って、運針を通常に戻し、ホスト５１、５２等の通信宛先からのレスポンスを受信できるようにする。

ＡＰＩ制御部４１は、マルウエア９のＡＰＩの呼び出しに応じて、スチールＡＰＩ選択ＤＢ３１を参照して、ＯＳカーネル７ｋのＡＰＩとして振舞うか、ＯＳカーネル７ｋのＡＰＩを呼び出すかを制御する。

マルウエア９等のソフトウェアは、通信ＡＰＩ７１１、時計ＡＰＩ７２１、その他のＡＰＩ７３１を呼び出すことで動作している。一般的なＯＳの時間関連のＡＰＩ（時計ＡＰＩ）には、主に２種類のタイマに関するＡＰＩが存在する。
・ハードウェアタイマに連動した時計機能へのＡＰＩ（時刻の取得）
例えば、gettimeofday()等である。
・タイマ割り込みに関するＡＰＩ（一定時間毎の間欠処理）
例えば、poll()、select()、signal()等である。

マルウエア９のＡＰＩの呼び出しが、通信ＡＰＩ、計時ＡＰＩ以外のその他のＡＰＩである場合、ＡＰＩ制御部４１は、サンドボックス環境８を介して、ＯＳカーネル７ｋのＡＰＩを呼び出す。一方、時計ＡＰＩの場合、ＡＰＩ制御部４１は、サンドボックス環境８が提供する時計ＡＰＩ制御部８０を呼び出す。

サンドボックス環境８は、他のプログラムやデータなどを操作できない保護された領域を提供する。サンドボックス環境８により、マルウエア９を動作させたとしても、マルウエア９による影響が及ばないように動態解析システム１０００全体を保護することができる。

サンドボックス環境８は、ＯＳ上の隔離環境の１プロセスとして動作する。、主に、計時ＡＰＩ制御部８０と、時計間隔調整部８２とを提供する。計時ＡＰＩ制御部８０と、時計間隔調整部８２とは、時間に係る処理に関して、あたかもＯＳカーネル７ｋのＡＰＩが呼び出されたかのように処理を行い、その結果をＡＰＩ制御部４１を介してマルウエア９へ提供する処理部である。

計時ＡＰＩ制御部８０は、マルウエア９によるＯＳカーネル７ｋの計時ＡＰＩ７２１の呼び出しに対して、調整された計時間隔に基づいて、ＯＳカーネル７ｋに代わって、時刻関連の処理を実行する。

計時ＡＰＩ制御部８０は、タイマ割込ＡＰＩ８１１と、タイマ割込ＡＰＩ制御部８１２と、時刻取得ＡＰＩ８２１と、時刻取得ＡＰＩ制御部８２２とを有する。

タイマ割込ＡＰＩ８１１は、マルウエア９の計時ＡＰＩ７２１の呼び出しに応じて、ＡＰＩ制御部４１によって、タイマ割り込みの場合に呼び出されるインタフェースである。タイマ割込ＡＰＩ制御部８１２は、タイマ割込ＡＰＩ８１１を介して実行される処理部であり、計時間隔調整部８２によって調整された計時間隔に基づいた時刻でタイマ割込を行う。

時刻取得ＡＰＩ８２１は、マルウエア９の計時ＡＰＩ７２１の呼び出しに応じて、ＡＰＩ制御部４１によって、時刻取得の場合に呼び出されるインタフェースである。時刻取得ＡＰＩ制御部８２２は、時刻取得ＡＰＩ８２１を介して実行される処理部であり、計時間隔調整部８２によって調整された計時間隔に基づいた時刻を提供する。

時計間隔調整部８２は、時計調整指示部６１による時刻の運針の倍率を示す計時指示に基づいて時計間隔を調整する。時計間隔調整部８２は、時計調整指示部６１から指示された運針の倍率をタイマ管理テーブル４３に記憶して管理し、タイマ管理テーブル４３を参照することによって、通常時間をタイマ倍率を用いて変換した時間を計時ＡＰＩ制御部に提供する。

タイマ管理テーブル４３は、計時調整指示部６１によって指示された運針の倍率を管理するテーブルであり、記憶部１３０内の時計間隔調整部８２に割り当てられた記憶領域に記憶される。

計時調整指示部６１は、ＯＳカーネル７ｋの計時ＡＰＩとサンドボックス環境８の計時とを比較してタイマの運針を速くするか、遅くするかを計時間隔調整部８２に指示する。この仕組みによりタイマの運針が調整される。計時調整指示部６１は、動態解析の実行時に、タイマをプリセットする。

計時調整指示部６１が計時を通常時間より遅く指示するとは、時刻の運針を遅くすることを意味する。時刻の運針が負（−）の方向に設定される。例えば、「−１」は、通常時の運針に対して３／４倍の速度への調整、「−２」は、通常時の運針に対して１／２倍の速度への調整を示し、「−４」は、通常時の運針に対して１／４倍の速度への調整等に、予め定められる。

また、計時調整指示部６１が計時を通常時間より速く指示するとは、時刻の運針を早くすることを意味する。時刻の運針が正（＋）の方向に設定される。例えば、「＋１」は、通常時の運針に対して３／２倍の速度への調整、「＋２」は、通常時の運針に対して２倍の速度への調整を示し、「＋４」は、通常時の運針に対して９／４倍の速度への調整等に、予め定められる。

ＯＳカーネル７ｋは、プログラムに提供される種々のＡＰＩとして、通信ＡＰＩ７１１、計時ＡＰＩ７２１、及びその他のＡＰＩ７３１と、夫々ＡＰＩに対応する通信処理部７１２、計時処理部７２２、その他の処理部７３２を有する。本実施例では、ＡＰＩ制御部４１を介して、種々のＡＰＩがマルウエア９に提供される。

通信ＡＰＩ７１１は、マルウエア９からの呼び出しにより、ネットワーク４上のホスト５１、５２等や、ルータ６を介した外部装置との通信を行うためのインタフェースに相当する。通信処理部７１２は、通信ＡＰＩ７１１を介してマルウエア９からホスト５１、５２等の外部装置への通信を行う。

計時ＡＰＩ７２１は、マルウエア９からの呼び出しにより、ＯＳの時計を変更するためのインタフェースに相当する。時計処理部７２２は、計時ＡＰＩ７２１を介してマルウエア９から時刻設定等に応じた処理を行う。

その他のＡＰＩ７３１は、マルウエア９とその他の処理部７３２とのインタフェースに相当する。その他の処理部７３２は、その他のＡＰＩ７３１を介してマルウエア９からの要求に応じた処理を行う。

上述した動態解析サーバ１００の機能構成において、マルウエア９が通信系のＡＰＩを呼び出した場合について説明する。図４は、通信系のＡＰＩを呼び出した場合を説明するための図である。図４では、図３の全体の機能構成のうち説明に必要な構成部分のみを示す。

図４において、マルウエア９が動作開始後、通信ＡＰＩを呼び出すと、ＡＰＩ制御部４１の通信宛先管理部４２が、通信宛先管理部４２は、通信管理テーブル４２ａを用いて、通信状態を管理した後、ノード管理テーブル４２ｂを参照して、通信宛先のノードが実在すると判断した場合、通信宛先管理部４２は、ＯＳカーネル７ｋの通信ＡＰＩ７１１を呼び出して、通信処理部７１２による通信を行わせる。

マルウエア９が呼び出す通信ＡＰＩは、send()、recv()、sendto()、recvfrom()、 bind()、connect()等である。

通信に関するｆｄが、例えば、
bind()
connect()
の場合、指定されたアドレスのエンドポイントに対応するｆｄが使用される。通信宛先管理部４２は、通信宛先毎に通信管理テーブル４２ａで管理されているｆｄが使用される場合、計時間隔調整部８２に時刻を通常の運針に戻す通常運針指示を行う。

一方、通信宛先のノードが実在しないと判断した場合、ＯＳカーネル７ｋの通信ＡＰＩ７１１を呼ぶことなく、ルータ６に代わって、マルウエア９へ通信エラーを通知する。このように、マルウエア９によるＡＰＩ呼び出しに対して通信エラーで即時復帰させることにより、探索捜査に掛かる時間を削減でき、高速に処理を行うことができる。

次に、マルウエア９が計時関係のＡＰＩを呼び出した場合について説明する。図５は、計時関係のＡＰＩを呼び出した場合を説明するための図である。図５では、図３の全体の機能構成のうち説明に必要な構成部分のみを示す。

図５において、マルウエア９が動作開始後、計時ＡＰＩを呼び出しに対して、ＡＰＩ制御部４１は、スチールＡＰＩ選択ＤＢ３１を参照して、ＡＰＩが計時調整を行う対象の処理であると判断した場合、サンドボックス環境８の計時ＡＰＩ制御部８０を呼び出す。

計時ＡＰＩ制御部８０において、タイマ割込ＡＰＩ８１１が呼び出された場合、タイマ割込ＡＰＩ制御部８１２は、計時間隔調整部８２から、通常時間より遅く又は速くなるように調整された計時間隔に基づく時間（調整時間と言う）を取得して、取得した調整時間でタイマ割り込み行う。マルウエア９は、調整時間を通常時間として扱って、調整時間に基づいてタイマ割り込みで処理を行う。

また、計時ＡＰＩ制御部８０において、時刻取得ＡＰＩ８２１が呼び出された場合、時刻取得ＡＰＩ制御部８２２は、計時間隔調整部８２から、通常時間より遅く又は速くなるように調整された計時間隔に基づく調整時刻を取得して、取得した調整時刻をマルウエア９に通知する。マルウエア９は、調整時間を通常時間として取得する。

図６は、スチールＡＰＩ選択ＤＢのデータ構成例を示す図である。図６において、スチールＡＰＩ選択ＤＢ３１は、ＡＰＩ名称、ＡＰＩ種類、引数等の項目を有する。

ＡＰＩ名称は、マルウエア９等のプログラムから呼び出し可能なＡＰＩの名称を示す。ＡＰＩ種類は、ＡＰＩ毎に通信系のＡＰＩか、時計関係のＡＰＩかを示す。通信系のＡＰＩの場合、ＡＰＩ種類は「１」を示す。時計関係のＡＰＩの場合、ＡＰＩ種類は「０」を示す。引数は、ＡＰＩ毎に定義された引数を示す。

図７は、各種テーブルのデータ構成例を示す図である。図７において、通信管理テーブル４２ａは、ファイルディスクリプタ（ｆｄ）、通信状態等の項目を有する。ファイルディスクリプタ（ｆｄ）は、ファイルディスクリプタを識別する識別子を示す。通信状態は、ファイルディスクリプタ毎に通信状態を示す。通信状態「１」は通信中を示し、「０」は未通信を示す。

ノード管理テーブル４２ｂは、実在するノードのＩＰアドレスを管理するテーブルであり、実在ノードのＩＰ等の項目を有する。この例では、図１に対応させて、ホスト５１のＩＰアドレス「１９２．１６３．０．１１」と「１９２．１６３．０．１２」とが記憶されている。

タイマ管理テーブル４３は、ｆｄ毎に時刻の運針を記憶するテーブルであり、ファイルディスクリプタ（ｆｄ）、時刻の運針速度（倍率）等の項目を有する。この例では、ｆｄ「４」のみが通常の運針速度の「１」（１倍）を示し、ｆｄ「３」では、時計を通常時間に対して＋２方向（２倍）に早くすることを示し、ｆｄ「５」では、時計を通常時間に対して−２方向（１／２倍）に遅くすることを示している。

次に、動態解析サーバ１００における動態解析処理について説明する。図８及び図９は、動態解析処理を説明するための図である。図８及び図９で説明される動態解析処理は、動態解析サーバ１００のＣＰＵ１１が動態解析プログラムを実行することにより実現される。

図８において、サンドボックス実行ランチャー９１からの指示に応じて、実行するマルウエア９がサンドボックス環境８に読み込まれる（ステップＳ１１）。

ＡＰＩ制御部４１は、マルウエア９（プログラム）から次に実行する命令が読み込むと（ステップＳ１２）、スチールＡＰＩ選択ＤＢ３１を検索して、ＡＰＩ種別３１ａを取得する（ステップＳ１３）。取得したＡＰＩ種別３１ａは、記憶部１３０の作業領域に一時的に格納される。

計時調整指示部６１が計時間隔調整部４２に実行速度を指示すると（ステップＳ１４）、計時間隔調整部４２は、基準クロックに対する実行時間の倍率を計算してタイマ管理テーブル４３に設定する（ステップＳ１５）。

そして、ＡＰＩ制御部４１は、ＡＰＩ種別３１ａに基づいて、実行するＡＰＩは、通信系のＡＰＩ呼び出しか否かを判断する（ステップＳ１６）。通信系のＡＰＩの場合、ＡＰＩ制御部４１は、図９のステップＳ２０へと進む。一方、通信系のＡＰＩでない場合、ＡＰＩ制御部４１は、更に、実行するＡＰＩは計時関係のＡＰＩ呼び出しか否かを判断する（ステップＳ１７）。計時関係のＡＰＩである場合、ＡＰＩ制御部４１は、図９のステップＳ２５へと進む。

一方、計時関係のＡＰＩでない場合、ＡＰＩ制御部４１は、実行したＡＰＩと実行結果とをログＤＢ３２に記録する（ステップＳ１８）。ログＤＢ３２は、記憶部１３０に記憶され、プログラム（この例ではマルウエア９）のＡＰＩ呼び出し毎にＡＰＩを特定するＡＰＩ名と、ＡＰＩ呼び出しによって実行された処理の結果とが記録される。

その後、ＡＰＩ制御部４１は、マルウエア９は動作を終了したか否かを判断する（ステップＳ１９）。動作を終了していない場合、ＡＰＩ制御部４１は、ステップＳ１２へと戻り、上述同様の処理を行う。

図９にて、図８のステップＳ１７において、実行するＡＰＩが通信系のＡＰＩ呼び出しであると判断した場合、ＡＰＩ制御部４１の通信宛先管理部４２は、通信管理テーブル４２ａの該当するｆｄに対して状態を通信中に設置する（ステップＳ２０）。そして、通信宛先管理部４２は、ｆｄに該当する宛先がノード管理テーブル４２ｂに存在するか否かを判断する（ステップＳ２１）。

ｆｄに該当する宛先が存在しない場合、通信宛先管理部４２は、宛先アドレスに該当するノードが存在しないため、実際に通信を行わずＡＰＩは正常復帰させ（ステップＳ２１−２）、ＡＰＩ制御部４１は、図８のステップＳ１２へと戻り、上述同様の処理を実行する。

ｆｄに該当する宛先が存在する場合、通信宛先管理部４２は、更に、タイマ割り込みが使用中であるか否かを判断する（ステップＳ２２）。タイマ割り込みが使用中である場合、通信中の時刻の運針を通常の基準クロック（１倍）に戻す通常運針指示を計時間隔調整部８２に行って（ステップＳ２２−２）、ステップＳ２４へと進む。

ここでの通常運針指示では、割り込み設定時刻までの経過時間が通常の基準クロック（即ち、１倍）にリセットすることが指示される。計時間隔が２倍速で動態解析が行われていた場合、計時間隔が１倍速にリセットされることにより、割り込み設定時刻が先延ばしされることになる。レスポンスを正常に受信するためである。通信が正常に終了した後は、計時調整指示部６１が指定した計時間隔でタイマ割り込みが行われる。

一方、タイマ割り込みが使用中でない場合、通信宛先管理部４２は、通信中の時刻の運針を通常に戻す通常運針指示を計時間隔調整部８２に行って、時刻の運針を通常の基準クロック（１倍）に合わせる（ステップＳ２３）。ここでの通常運針指示では、タイマ割り込みがないため、単に、計時間隔が１倍速にリセットすることが指示される。

通信宛先管理部４２は、ＯＳカーネル７ｋの通信ＡＰＩ７１１を呼び出して（ステップＳ２４）、図８のステップＳ１２へと戻り、上述同様の処理を繰り返す。

図８のステップＳ１７において、実行するＡＰＩが計時関係のＡＰＩ呼び出しであると判断した場合、図９にて、ＡＰＩ制御部４１は、時計管理を行い（ステップＳ２５）、ＡＰＩ種別３１ａを参照して、タイマ割り込みＡＰＩか否かを判断する（ステップＳ２６）。

タイマ割り込みＡＰＩでない場合、ＡＰＩ制御部４１は、時計ＡＰＩ制御部８０の時刻取得ＡＰＩ８２２を呼び出す。時計ＡＰＩ制御部８０の時刻取得ＡＰＩ制御部８２２は、時刻の運針に合わせたタイマ割り込み時間を計時間隔調整部８２に問い合わせして（ステップＳ２７）、計時間隔調整部８２から取得した時刻を時刻取得ＡＰＩ８２１に通知する（ステップＳ２８）。その後、ＡＰＩ制御部４１は、図８のステップＳ１２へ戻り、上述同様の処理を繰り返す。

一方、タイマ割り込みＡＰＩの場合、ＡＰＩ制御部４１は、時刻の運針に合わせたタイマ割り込み時間を計時間隔調整部８２に設定して（ステップＳ２７−２）、計時間隔調整部８２は割り込み設定完了をタイマ割込ＡＰＩ８１１に通知する（ステップＳ２８−２）。その後、ＡＰＩ制御部４１は、図８のステップＳ１２へ戻り、上述同様の処理を繰り返す。

以下に、計時を通常時間より早く又は遅く調整した夫々の時計調整の場合について説明する。先ず、計時を通常時間の２倍に早くした場合、即ち、時刻の運針を２倍速くするプリセットを行った場合について説明する。

図１０は、２倍速の場合を説明するための図である。図１０において、時計調整指示部６１が、時計を通常時間の２倍にする計時指示を計時間隔調整部８２に指示した場合の、（ａ）ソフトウェア割込処理、（ｂ）時刻取得処理、及び（ｃ）通信ＡＰＩ処理の概要を示す。計時間隔調整部８２は、時計調整指示部６１からの２倍速の計時指示に応じて、割込間隔及び割込時刻を変換する。

図１１は、ＯＳカーネルのＡＰＩの呼び出し例を示す図である。
（ａ）ソフトウェア割込ＡＰＩの例として、sleep(unsigned int seconds)でＡＰＩ呼び出しが行われる。引数secondsで秒数が指定される。
（ｂ）時刻取得ＡＰＩの例として、time(time_t *tloc)でＡＰＩ呼び出しが行われる。引数tlocによって秒数が戻り値として設定される。
（ｃ）通信ＡＰＩの例として、bind(int socket, const struct sockaddr *address, socklen_t addr_len)でＡＰＩ呼び出しが行われる。引数socketでソケットｆｄが指定され、sockaddr構造体へのポインタであるaddressによってアドレスが指定される。また、引数addr_lenでアドレス長が示される。

（ａ）ソフトウェア割込処理では、マルウエア９が上述したようなソフトウェア割込ＡＰＩを呼び出す。マルウエア９によってタイマ割込ＡＰＩ８１１が呼び出され、タイマ割込制御部８１２に１０秒毎の割込が指示される。

１０秒毎の割込指示に対して、時計ＡＰＩ制御部８０のタイマ割込制御部８１２は、時計間隔調整部８２に対してＯＳカーネル７ｋへの１０秒毎の割込指示を要求する。時計間隔調整部８２は、時計調整指示部６１による時計の運針を２倍速にする指示に基づいて、１０秒の１／２の間隔である５秒で割り込みを行うようＯＳカーネル７ｋへ要求する。

ＯＳカーネル７ｋからの５秒毎の割り込みは、時計間隔調整部８２を介してタイマ割込ＡＰＩ制御部８１２に通知され、タイマ割込ＡＰＩ制御部８１２は、タイマ割込ＡＰＩ８１１を介してマルウエア９に割り込みを発生させる。

（ｂ）時刻取得処理では、マルウエア９が上述したような時刻取得ＡＰＩを呼び出す。マルウエア９によって時刻取得ＡＰＩ８２１が呼び出されることにより、時刻取得ＡＰＩ制御部８２２は、時計間隔調整部８２を介してＯＳカーネル７ｋから時刻を取得する。ＯＳカーネル７ｋから通知される時刻は通常時刻である。

通常時刻は、計時間隔調整部８２によって時計調整指示部６１が指定した時計の運針（２倍）に換算され、時刻取得ＡＰＩ制御部８２２に通知される。時刻取得ＡＰＩ制御部８２２に通知された時刻は、時刻取得ＡＰＩ８２１の呼び出しに対する戻り値としてマルウエア９へ通知される。マルウエア９は、２倍速で換算された時刻を取得する。

（ｃ）通信ＡＰＩ処理では、マルウエア９が上述したような通信ＡＰＩを呼び出す。ＡＰＩ制御部４１の通信宛先管理部４２は、サンドボックス環境８に対して通常運針に戻す通常運針指示を行う。

サンドボックス８に宛先アドレス依存処理部８３を備え、宛先アドレス依存処理部８３で通常運針指示を受けるようにしても良い。宛先アドレス依存処理部８３は、通信ＡＰＩで指定されたｆｄに関して通信中は通常運針に戻す指示を時計間隔調整部８２に行う。また、宛先アドレス依存処理部８３は、ＯＳカーネル７ｋの通信ＡＰＩ７１１を呼び出す。宛先アドレス依存処理部８３は、ｆｄ毎に通信中の管理を行い、レスポンスを正常に受信し、マルウエア９へ通信ＡＰＩ呼び出しに対して応答できるようにする。

マルウエア９からの通信以外のＡＰＩの呼び出しでは、サンドボックス環境８を介してＯＳカーネル７ｋが提供するＡＰＩが直接呼び出される。

図１２は、２倍速の場合のソフトウェア割込処理を説明するためのフローチャート図である。図１２において、ＡＰＩ制御部４１は、マルウエア９からpoll ＡＰＩ呼び出しで１０秒毎の割り込みを指示した割込指示を受信する（ステップＳ１１１）。

ＡＰＩ制御部４１では、スチールＡＰＩ選択ＤＢ３１（図６）よりＡＰＩの種類が時刻であることから、通信ＡＰＩの呼び出しではないと判断し、ＡＰＩ制御部４１の通信先管理部４２が、通信管理テーブル４２ａを参照して通信系のＡＰＩでｆｄが実行中か否かを判断する（ステップＳ１１２）。

通信系のＡＰＩが実行中でない場合（ステップＳ１１２のＮＯ）、通信先管理部４２は、poll ＡＰＩに対応する時計ＡＰＩ制御部８０のタイマ割込ＡＰＩ８１１を呼び出す。タイマ割込ＡＰＩ制御部８１２は、マルウエア９の割込指示から割り込み間隔（例えば、１０秒）を取得して、時計間隔調整部８２に通知する（ステップＳ１１３）。

時計間隔調整部８２は、時計調整指示部６１から指示された時計の運針（２倍）に変換した割り込み間隔（５秒）をＯＳカーネル７ｋに設定する（ステップＳ１１４）。その後、ＯＳカーネル７ｋからのソフトウェア割り込みの通知がタイマ割込ＡＰＩ制御部８１２に通知する（ステップＳ１１５）。ソフトウェア割込処理を終了する。

一方、ＡＰＩ制御部４１において、通信系のＡＰＩが実行中であると判断された場合（ステップＳ１１２のＹＥＳ）、通信先管理部４２は、ノード管理テーブル４２ｂを参照して、poll ＡＰＩで指定される通信相手先（ノード）が実在するか否かをチェックする（ステップＳ１１２−２）。

実在した場合（ステップＳ１１２−２のＹＥＳ）、通信先管理部４２は、通常運針指示を宛先アドレス依存処理部８３に通知する。宛先アドレス依存処理部８３は、割り込み間隔を通常の運針に戻して、割り込み間隔（１０秒）をＯＳカーネル７ｋに設定する（ステップＳ１１４−２）。その後、ＯＳカーネル７ｋからのソフトウェア割り込みの通知がタイマ割込ＡＰＩ制御部８１２に通知する（ステップＳ１１５）。ソフトウェア割込処理を終了する。

図１３は、２倍速の場合の時刻取得処理を説明するためのフローチャート図である。図１３において、ＡＰＩ制御部４１は、マルウエア９からgettimeofday()ＡＰＩで時刻取得要求を受信する（ステップＳ１２１）。ＡＰＩ制御部４１は、gettimeofday()ＡＰＩに対応する時刻取得ＡＰＩ８２１を介して時刻取得ＡＰＩ制御部８２２に処理を渡す。

時刻取得ＡＰＩ８２１は、時刻が記憶されている時刻格納領域を時計間隔調整部８２に通知する（ステップＳ１２２）。時計間隔調整部８２は、ＯＳカーネル７ｋから現在時刻を取得する（ステップＳ１２３）。

時計間隔調整部８２は、通信系のＡＰＩが実行中か否かを判断する（ステップＳ１２４）。通信系のＡＰＩが実行中でない場合（ステップＳ１２４のＮＯ）、時計間隔調整部８２は、ＯＳカーネル７ｋから取得した時刻を、時計間隔調整部８２で設定された時計の運針（２倍）に換算して、時刻取得ＡＰＩ制御部８２２に通知する（ステップＳ１２５）。時刻取得ＡＰＩ制御部８２２によって、換算された時刻がマルウエア９に通知され、時刻取得処理は終了する。

一方、通信系のＡＰＩが実行中の場合（ステップＳ１２４のＹＥＳ）、時計間隔調整部８２は、ＯＳカーネル７ｋから取得した時刻を、そのまま時刻取得ＡＰＩ制御部８２２に通知する（ステップＳ１２６）。この場合、時刻取得ＡＰＩ制御部８２２によって、通常時刻がマルウエア９に通知され、時刻取得処理は終了する。

図１４は、２倍速の場合の通信ＡＰＩ処理を説明するためのフローチャート図である。図１４において、マルウエア９のファイルの通信ＡＰＩ呼び出しにより通信要求を受信すると（ステップＳ１３１）、ＡＰＩ制御部４１は、通信ＡＰＩの使用を検出し、通常運針指示を宛先アドレス依存処理部８３に対して行う（ステップＳ１３２）。

ＡＰＩ制御部４１の通信先管理部４２は、通信ＡＰＩの呼び出しで指定されたｆｄの宛先ノードが存在するか否かを判断する（ステップＳ１３３）。存在しない場合（ステップＳ１３３のＮＯ）、通信先管理部４２は、存在しないノードへの要求に対してＡＰＩを正常復帰させて（ステップＳ１３３−２）、この２倍速の場合の通信ＡＰＩ処理を終了する。

一方、存在する場合（ステップＳ１３３のＹＥＳ）、通信先管理部４２はｆｄを宛先アドレス依存処理部８３に通信ＡＰＩが使用する通知し、宛先アドレス依存処理部８３は、時間間隔調整部８２にそのｆｄを通知する（ステップＳ１３４）。時計間隔調整部８２は、通信ＡＰＩが使用するｆｄに関して、「通信中」は運針を通常に戻す。

また、宛先アドレス依存処理部８３は、ＯＳカーネル７ｋに対して通信ＡＰＩ７１１を呼び出す（ステップＳ１３５）。通信相手先からレスポンスを受信すると、宛先アドレス依存処理部８３は、時計間隔調整部８２に通信終了とｆｄとを通知し、マルウエア９に対してレスポンスを通知して、通信ＡＰＩ処理は終了する。時計間隔調整部８２は、レスポンスの受信によるｆｄの通知によって、一時的に通常に戻していた運針を、時計調整指示部６１によって指示されていた運針の倍率に戻す。

上述した通信ＡＰＩ処理によって、「通信中」は運針が通常に戻されるため、レスポンスを正常に受信でき、通信エラーを回避することができる。また、通信の終了によって、運針の速度を時計調整指示部６１によって指示されていた運針の倍率に合わせるため、マルウエア９の動態解析を効果的に行うことができる。

図１５は、２倍速の場合の観測時間の比較例を示す図である。図１５において、マルウエア９の動態解析を通常時間で行った場合と、本実施例における調整して時間を２倍速にした場合の観測時間の差を例示している。この例では、マルウエア９により１０秒毎のソフトウェア割込処理（ａ）が指定されたとする。

通常時間では、時間調整を行わず通常時間をマルウエア９に提供して観測した場合のマルウエア９（収集したプログラム）の挙動例を示している。マルウエア９は、起動後凡そ１０分後にＣ＆Ｃサーバと接続した後、凡そ３０分後に周辺を探索開始する。

マルウエア９は、多数のＩＰアドレスをランダムで生成し、１０秒間隔でネットワーク４に送出して探索する。その後、マルウエア９は、存在するＩＰアドレスのホスト、サーバ等の装置からレスポンスを得る。

凡そ６０分後に、マルウエア９は、探索によりレスポンスを得られた周辺装置に対して感染させて、目的の情報を収集する。凡そ２４時間後、マルウエア９は、感染した周辺装置から収集して得た情報収集結果をＣ＆Ｃサーバへ提供する。

この例では、凡そ１０分後にマルウエア９が活動を開始した例を示しているが、マルウエア９は、感染後にすぐに活動するとは限らない。一定時間が経過しないと動作開始しない場合であっても、観測し続けなければならない。

２倍速では、本実施例を適用して通常時間を１／２に短縮してマルウエア９に提供して観測した場合のマルウエア９（収集したプログラム）の挙動例を示している。通信中以外では、時間が２倍の早さで進むため、マルウエア９は２倍速く動作する。凡そ５分後にマルウエア９は、Ｃ＆Ｃサーバと接続した後、凡そ１５分後に周辺を探索開始する。

マルウエア９は、多数のＩＰアドレスをランダムで生成し、５秒間隔でネットワーク４に送出して探索する。本実施例では、ＡＰＩ制御部４１の通信制御により、ネットワーク４に存在するノードに対してのみ通信が行われ、存在しないノードへの通信は抑制される。従って、マルウエア９による探索処理に要する時間を大幅に短縮することができる。マルウエア９は、存在するＩＰアドレスのホスト、サーバ等の装置からレスポンスを得る。

凡そ３０分後、探索によりレスポンスを得られた周辺装置に対して感染させて、目的の情報を収集する。凡そ１２時間後、マルウエア９は、感染した周辺装置から収集して得た情報収集結果をＣ＆Ｃサーバへ提供する。

通常時間では凡そ２４時間の観測に対して、本実施例における２倍速では、凡そ１２ｈの観測となり、マルウエア９の挙動を解析する時間を大幅に短縮することが可能である。

次に、計時を通常時間の１／２倍に遅くした場合、即ち、時刻の運針を１／２倍遅くするプリセットを行った場合について説明する。

図１６は、１／２倍の場合を説明するための図である。図１６において、時計調整指示部６１が、時計を通常時間の２倍にする計時指示を計時間隔調整部８２に指示した場合の、（ａ）ソフトウェア割込処理、（ｂ）時刻取得処理、及び（ｃ）通信ＡＰＩ処理の概要を示す。計時間隔調整部８２は、時計調整指示部６１からの２倍速の計時指示に応じて、割込間隔及び割込時刻を変換する。ＯＳカーネルのＡＰＩの呼び出し例については、上述した２倍速の場合と同様である。

（ａ）ソフトウェア割込処理では、マルウエア９が２倍速の場合で説明したようなソフトウェア割込ＡＰＩを呼び出す。マルウエア９によってタイマ割込ＡＰＩ８１１が呼び出され、タイマ割込制御部８１２に１０秒毎の割込が指示される。

１０秒毎の割込指示に対して、時計ＡＰＩ制御部８０のタイマ割込制御部８１２は、時計間隔調整部８２に対してＯＳカーネル７ｋへの１０秒毎の割込指示を要求する。時計間隔調整部８２は、時計調整指示部６１による時計の運針を１／２倍速にする指示に基づいて、１０秒の２倍の間隔である２０秒で割り込みを行うようＯＳカーネル７ｋへ要求する。

ＯＳカーネル７ｋからの２０秒毎の割り込みは、時計間隔調整部８２を介してタイマ割込ＡＰＩ制御部８１２に通知され、タイマ割込ＡＰＩ制御部８１２は、タイマ割込ＡＰＩ８１１を介してマルウエア９に割り込みを発生させる。

（ｂ）時刻取得処理では、マルウエア９が２倍速の場合で説明したような時刻取得ＡＰＩを呼び出す。マルウエア９によって時刻取得ＡＰＩ８２１が呼び出されることにより、時刻取得ＡＰＩ制御部８２２は、時計間隔調整部８２を介してＯＳカーネル７ｋから時刻を取得する。ＯＳカーネル７ｋから通知される時刻は通常時刻である。

通常時刻は、計時間隔調整部８２によって時計調整指示部６１が指定した時計の運針（１／２倍）に換算され、時刻取得ＡＰＩ制御部８２２に通知される。時刻取得ＡＰＩ制御部８２２に通知された時刻は、時刻取得ＡＰＩ８２１の呼び出しに対する戻り値としてマルウエア９へ通知される。マルウエア９は、１／２倍速で換算された時刻を取得する。

（ｃ）通信ＡＰＩ処理では、マルウエア９が上述したような通信ＡＰＩを呼び出す。ＡＰＩ制御部４１の通信宛先管理部４２は、サンドボックス環境８に対して通常運針に戻す通常運針指示を行う。

サンドボックス８に宛先アドレス依存処理部８３を備え、宛先アドレス依存処理部８３で通常運針指示を受けるようにしても良い。宛先アドレス依存処理部８３は、通信ＡＰＩで指定されたｆｄに関して通信中は通常運針に戻す指示を時計間隔調整部８２に行う。また、宛先アドレス依存処理部８３は、ＯＳカーネル７ｋの通信ＡＰＩ７１１を呼び出す。宛先アドレス依存処理部８３は、ｆｄ毎に通信中の管理を行い、レスポンスを正常に受信し、マルウエア９へ通信ＡＰＩ呼び出しに対して応答できるようにする。

マルウエア９からの通信以外のＡＰＩの呼び出しでは、２倍速の場合と同様に、サンドボックス環境８を介してＯＳカーネル７ｋが提供するＡＰＩが直接呼び出される。

図１７は、１／２倍速の場合のソフトウェア割込処理を説明するためのフローチャート図である。図１７において、ＡＰＩ制御部４１は、マルウエア９からpoll ＡＰＩ呼び出しで１０秒毎の割り込みを指示した割込指示を受信する（ステップＳ２１１）。

ＡＰＩ制御部４１では、スチールＡＰＩ選択ＤＢ３１（図６）よりＡＰＩの種類が時刻であることから、通信ＡＰＩの呼び出しではないと判断し、ＡＰＩ制御部４１の通信先管理部４２が、通信管理テーブル４２ａを参照して通信系のＡＰＩでｆｄが実行中か否かを判断する（ステップＳ２１２）。

通信系のＡＰＩが実行中でない場合（ステップＳ２１２のＮＯ）、通信先管理部４２は、poll ＡＰＩに対応する時計ＡＰＩ制御部８０のタイマ割込ＡＰＩ８１１を呼び出す。タイマ割込ＡＰＩ制御部８１２は、マルウエア９の割込指示から割り込み間隔（例えば、１０秒）を取得して、時計間隔調整部８２に通知する（ステップＳ２１３）。

時計間隔調整部８２は、時計調整指示部６１から指示された時計の運針（１／２倍）に変換した割り込み間隔（２０秒）をＯＳカーネル７ｋに設定する（ステップＳ２１４）。その後、ＯＳカーネル７ｋからのソフトウェア割り込みの通知がタイマ割込ＡＰＩ制御部８１２に通知する（ステップＳ２１５）。ソフトウェア割込処理を終了する。

一方、ＡＰＩ制御部４１において、通信系のＡＰＩが実行中であると判断された場合（ステップＳ２１２のＹＥＳ）、通信先管理部４２は、ノード管理テーブル４２ｂを参照して、poll ＡＰＩで指定される通信相手先（ノード）が実在するか否かをチェックする（ステップＳ１２２−２）。

実在した場合（ステップＳ２１２−２のＹＥＳ）、通信先管理部４２は、通常運針指示を宛先アドレス依存処理部８３に通知する。宛先アドレス依存処理部８３は、割り込み間隔を通常の運針に戻して、割り込み間隔（２０秒）をＯＳカーネル７ｋに設定する（ステップＳ２１４−２）。その後、ＯＳカーネル７ｋからのソフトウェア割り込みの通知がタイマ割込ＡＰＩ制御部８１２に通知する（ステップＳ１１５）。ソフトウェア割込処理を終了する。

図１８は、１／２倍速の場合の時刻取得処理を説明するためのフローチャート図である。図１３において、ＡＰＩ制御部４１は、マルウエア９からgettimeofday()ＡＰＩで時刻取得要求を受信する（ステップＳ２２１）。ＡＰＩ制御部４１は、gettimeofday()ＡＰＩに対応する時刻取得ＡＰＩ８２１を介して時刻取得ＡＰＩ制御部８２２に処理を渡す。

時刻取得ＡＰＩ８２１は、時刻が記憶されている時刻格納領域を時計間隔調整部８２に通知する（ステップＳ２２２）。時計間隔調整部８２は、ＯＳカーネル７ｋから現在時刻を取得する（ステップＳ２２３）。

時計間隔調整部８２は、通信系のＡＰＩが実行中か否かを判断する（ステップＳ２２４）。通信系のＡＰＩが実行中でない場合（ステップＳ２２４のＮＯ）、時計間隔調整部８２は、ＯＳカーネル７ｋから取得した時刻を、時計間隔調整部８２で設定された時計の運針（１／２倍）に換算して、時刻取得ＡＰＩ制御部８２２に通知する（ステップＳ２２５）。時刻取得ＡＰＩ制御部８２２によって、換算された時刻がマルウエア９に通知され、時刻取得処理は終了する。

一方、通信系のＡＰＩが実行中の場合（ステップＳ２２４のＹＥＳ）、時計間隔調整部８２は、ＯＳカーネル７ｋから取得した時刻を、そのまま時刻取得ＡＰＩ制御部８２２に通知する（ステップＳ２２６）。この場合、時刻取得ＡＰＩ制御部８２２によって、通常時刻がマルウエア９に通知され、時刻取得処理は終了する。

図１９は、１／２倍速の場合の通信ＡＰＩ処理を説明するためのフローチャート図である。図１９において、マルウエア９のファイルの通信ＡＰＩ呼び出しにより通信要求を受信すると（ステップＳ２３１）、ＡＰＩ制御部４１は、通信ＡＰＩの使用を検出し、通常運針指示を宛先アドレス依存処理部８３に対して行う（ステップＳ２３２）。

ＡＰＩ制御部４１の通信先管理部４２は、通信ＡＰＩの呼び出しで指定されたｆｄの宛先ノードが存在するか否かを判断する（ステップＳ２３３）。存在しない場合（ステップＳ２３３のＮＯ）、通信先管理部４２は、存在しないノードへの要求に対してＡＰＩを正常復帰させて（ステップＳ２３３−２）、この１／２倍速の場合の通信ＡＰＩ処理を終了する。

一方、存在する場合（ステップＳ２３３のＹＥＳ）、通信先管理部４２はｆｄを宛先アドレス依存処理部８３に通信ＡＰＩが使用する通知し、宛先アドレス依存処理部８３は、時間間隔調整部８２にそのｆｄを通知する（ステップＳ２３４）。時計間隔調整部８２は、通信ＡＰＩが使用するｆｄに関して、「通信中」は運針を通常に戻す。

また、宛先アドレス依存処理部８３は、ＯＳカーネル７ｋに対して通信ＡＰＩ７１１を呼び出す（ステップＳ２３５）。通信相手先からレスポンスを受信すると、宛先アドレス依存処理部８３は、時計間隔調整部８２に通信終了とｆｄとを通知し、マルウエア９に対してレスポンスを通知して、通信ＡＰＩ処理は終了する。時計間隔調整部８２は、レスポンスの受信によるｆｄの通知によって、一時的に通常に戻していた運針を、時計調整指示部６１によって指示されていた運針の倍率に戻す。

上述した通信ＡＰＩ処理によって、「通信中」は運針が通常に戻されるため、レスポンスを正常に受信でき、通信エラーを回避することができる。また、通信の終了によって、運針の速度を時計調整指示部６１によって指示されていた運針の倍率に合わせるため、マルウエア９の動態解析を効果的に行うことができる。

図２０は、１／２倍速の場合の観測時間の比較例を示す図である。図２０において、マルウエア９の動態解析を通常時間で行った場合と、本実施例における調整して時間を１／２倍速にした場合の観測時間の差を例示している。この例では、マルウエア９により１０秒毎のソフトウェア割込処理（ａ）が指定されたとする。

通常時間では、時間調整を行わず通常時間をマルウエア９に提供して観測した場合のマルウエア９（収集したプログラム）の挙動例を示している。マルウエア９は、起動後凡そ１０分後にＣ＆Ｃサーバと接続した後、凡そ３０分後に周辺を探索開始する。

マルウエア９は、多数のＩＰアドレスをランダムで生成し、１０秒間隔でネットワーク４に送出して探索する。その後、マルウエア９は、存在するＩＰアドレスのホスト、サーバ等の装置からレスポンスを得る。

凡そ４０分後に、マルウエア９は、探索によりレスポンスを得られた周辺装置に対して感染させて、目的の情報を収集する。凡そ６０分後、マルウエア９は、感染した周辺装置から収集して得た情報収集結果をＣ＆Ｃサーバへ提供する。

この例では、凡そ１０分後にマルウエア９が活動を開始した例を示しているが、マルウエア９は、感染後にすぐに活動するとは限らない。一定時間が経過しないと動作開始しない場合であっても、観測し続けなければならない。

２倍速では、本実施例を適用して通常時間を２倍に延伸させてマルウエア９に提供して観測した場合のマルウエア９（収集したプログラム）の挙動例を示している。通信中以外では、時間が１／２倍の早さで進むため、マルウエア９は２倍遅く動作する。凡そ２０分後にマルウエア９は、Ｃ＆Ｃサーバと接続した後、凡そ４０分後に周辺を探索開始する。

マルウエア９は、多数のＩＰアドレスをランダムで生成し、２０秒間隔でネットワーク４に送出して探索する。本実施例では、ＡＰＩ制御部４１の通信制御により、ネットワーク４に存在するノードに対してのみ通信が行われ、存在しないノードへの通信は抑制される。マルウエア９が、存在するＩＰアドレスのホスト、サーバ等の装置からレスポンスを得る。

凡そ８０分後、探索によりレスポンスを得られた周辺装置に対して感染させて、目的の情報を収集する。凡そ１２０分後、マルウエア９は、感染した周辺装置から収集して得た情報収集結果をＣ＆Ｃサーバへ提供する。

１／２倍速での動態解析では、周辺装置への感染前からマルウエア９の情報収集結果がＣ＆Ｃサーバへ提供されるまでを、時間を掛けて行うことができる。マルウエア９の挙動を詳細に解析することができる。

マルウエア９は、ネットワーク４内で感染を広げるためにＩＰアドレスをランダムにスキャンし探索を行う。探索した結果、ネットワーク４に存在するホスト５１、５２等から応答があった場合、ホストが存在すると判断し、ホストを通信相手先に指定して感染パケットを送信する。このような、マルウエア９が行う探索処理では、ネットワーク４に対して大量のＩＰアドレスを生成して探索するため、応答のないＩＰアドレスが多い。

ネットワーク４に存在しないＩＰアドレスに対する探索処理を省略できるため、効率的にマルウエア９の動態解析を行うことができる。本実施例を適用しない場合と、本実施例を適用した場合の比較について図２１で説明する。

図２１は、マルウエアによる探索処理に関する比較例を示す図である。本実施例を適用しない場合（図２１（Ａ））と、本実施例を適用した場合（図２１（Ｂ））とにおいて、マルウエア９が、不在ホストａ、ｂ、ｃ、ｄ、ｅ、実在ホスト５１、・・・に対して探索を行った場合を示している。

図２１（Ａ）の本実施例を適用しない場合では、不在ホストａを通信相手先とした探索パケットを送信すると、ルータ６がエラー通知を示すパケットを送り返す。不在ホストｂを通信相手先とした探索パケットを送信すると、ルータ６がエラー通知を示すパケットを送り返す。

ルータ６からエラー通知がない、不在ホストｃ及びｅに対する探索パケットに対しては、動態解析サーバ１００のＯＳカーネル７ｋは、再送タイムアウトまで繰り返し探索パケットを送信し、再送タイムアウトで、ＯＳカーネル７ｋからエラー通知をマルウエア９に通知する。

時間Ｔａは、不在ホストａ〜ｅの夫々を指定した通信ＡＰＩ呼び出しから、エラー通知がマルウエア９に通知されるまでの時間長を示している。

実在するホスト５１を通信相手先とした探索パケットを送信した場合、ホスト５１からレスポンスが送信され、マルウエア９へ正常終了が通知される。

図２１（Ｂ）の本実施例を適用した場合では、ＡＰＩ制御部４１がマルウエア９からの通信ＡＰＩ呼び出しに対して、通信相手先となるノードが存在するか否かを判断する。不在ホストａ〜ｅに対しては、ＡＰＩ制御部４１で即時に正常終了をマルウエア９に通知する。従って、不在ホストａ〜ｅを指定した探索パケットがネットワーク４へ送出されることはない。

実在するホスト５１を指定した通信ＡＰＩ呼び出しに対しては、ＡＰＩ制御部４１がその存在を確認した上で、ネットワーク４へ探索パケットが送信され、ホスト５１から正常終了が返信される。

本実施例を適用した場合では、不在ホストａ〜ｅの夫々を指定した通信ＡＰＩ呼び出しから、エラー通知がマルウエア９に通知されるまでの時間長は、時間Ｔｂで示される。図２１（Ａ）の時間Ｔａと比べると、時間Ｔｂがより短い時間であることが分かる。不在ホストの数が多い程、本実施例による観測時間を短縮する効果は大きい。

本実施例では、時刻の運針を早く又は遅くした場合であっても通信異常を回避できることについて、本実施例を適用しない場合と比較して以下に説明する。

図２２は、２倍速の場合における通信異常回避を説明するための図である。図２２では、マルウエア９とホスト５２（例えばＤＮＳサーバ）との通信例を時間軸で示している。

図２２（Ａ）では、本実施例の適用無く、通信中においても２倍速で観測が行われた場合の例を示している。通信中は、ホスト５２は、通常時間に基づく単位時間ｔｕで動作し、マルウエア９は、単位時間ｔｕの２倍の早さの単位時間ｔｕ＿２で動作する。

従って、マルウエア９では、応答を受け取るまでのタイムアウト待ち時間Ｔ１が、ホスト５２の通常時間に基づく応答を受け取るまでのタイムアウト待ち時間Ｔ２に対して１／２に縮小される。ここで、マルウエア９側のタイムアウト待ち時間Ｔ１とホスト５２側のタイムアウト待ち時間Ｔ２とは、単位時間の長さは異なるものの、単位時間に基づくカウント値としては同じ値である。

マルウエア９が単位時間ｔｕ＿２でリクエストをホスト５２へ送信する。ホスト５２は、マルウエア９からのリクエストを受信して、そのリクエストに応じて正常にレスポンスを送信する。

マルウエア９では、通信中も２倍の早さで時間が経過するため、タイムアウト待ち時間Ｔ１の後にホスト５２からのレスポンスを受信する。よって、タイムアウトによる通信エラーとなる。

このように、単に、単位時間を短くした場合では、マルウエア９の動態解析を適切に行うことができない。

図２２（Ｂ）では、本実施例における動態解析サーバ１００でマルウエア９を観測し、通信中は通常時間に戻して観測が行われた場合の例を示している。マルウエア９のリクエスト送信時に、時刻の運針が基準クロック（１倍）に設定され（図９のステップＳ２２−２）、単位時間ｔｕ＿２が単位時間ｔｕに戻される。

従って、ホスト５２の単位時間ｔｕと一致し、ホスト５２がリクエストを受信して、レスポンスで返信した場合、マルウエア９は、タイムアウト待ち時間Ｔ２内で正常に受信し、通信を正常終了することができる。

図２３は、１／２倍速の場合における通信異常回避を説明するための図である。図２３では、マルウエア９とホスト５２（例えばＤＮＳサーバ）との通信例を時間軸で示している。

図２３（Ａ）では、本実施例の適用無く、通信中においても１／２倍速で観測が行われた場合の例を示している。通信中は、ホスト５２は、通常時間に基づく単位時間ｔｕで動作し、マルウエア９は、単位時間ｔｕの１／２倍の早さの単位時間ｔｕ＿３で動作する。

従って、マルウエア９では、応答を受け取るまでのタイムアウト待ち時間Ｔ３が、ホスト５２の通常時間に基づく応答を受け取るまでのタイムアウト待ち時間Ｔ２に対して２倍に延伸される。ここで、マルウエア９側のタイムアウト待ち時間Ｔ３とホスト５２側のタイムアウト待ち時間Ｔ２とは、単位時間の長さは異なるものの、単位時間に基づくカウント値としては同じ値である。

マルウエア９が単位時間ｔｕ＿３でリクエストをホスト５２へ送信する。ホスト５２は、マルウエア９からのリクエストを受信して、そのリクエストに応じて正常にレスポンスを送信する。

マルウエア９では、通信中も１／２倍の早さでゆっくりと時間が経過するため、ホスト５２からのレスポンスをリクエスト送信時の時間単位ｔｕ＿３内で受信してしまう。よって、受信待ちの状態前でホスト５２のレスポンスを受信することができず、通信エラーとなる。

このように、単に、単位時間を長くした場合では、マルウエア９の動態解析を適切に行うことができない。

図２３（Ｂ）では、本実施例における動態解析サーバ１００でマルウエア９を観測し、通信中は通常時間に戻して観測が行われた場合の例を示している。マルウエア９のリクエスト送信時に、時刻の運針が基準クロック（１倍）に設定され（図９のステップＳ２２−２）、単位時間ｔｕ＿３が単位時間ｔｕに戻される。

従って、ホスト５２の単位時間ｔｕと一致し、ホスト５２がリクエストを受信して、レスポンスで返信した場合、マルウエア９は、タイムアウト待ち時間Ｔ３内で正常に受信し、通信を正常終了することができる。

図２４は、マルウェアの処理フェーズにおける本実施例の効果を説明するための図である。図２４より、マルウェア９の処理（活動）フェーズには、実行又は感染、レジストリ登録、Ｃ＆Ｃサーバ接続、探索、そしてマルウエア本体のＤＬ感染の処理フェーズがある。

本実施例に係る動態解析サーバ１００においてマルウエア９を実行又は感染する実行又は感染の処理フェーズ、及びマルウエア９によるレジストリを登録するレジストリ登録の処理フェーズでは、時計調整指示部６１からの指示に従って時間間隔を短く又は長く調整した時間間隔でマルウエア９を観測する。時間間隔を短く調整した場合には、実行又は感染の処理フェーズ及びレジストリ登録の処理フェーズは高速化される。

Ｃ＆Ｃサーバ接続の処理フェーズからは、マルウエア９の処理は通信が大半を占めるため、時刻の運針は通常に戻される。Ｃ＆Ｃサーバ接続の処理フェーズでは、マルウエア９は通信を開始するため、タイムアウトのカウントを開始する。タイムアウトのカウント開始と共に、時刻の運針をリセットし、通常時間でマルウエア９を観測する。本実施例では、通信中に、時間間隔（単位時間の長さ）の調整による通信エラーが発生することはないため、マルウエア９の挙動が阻害されることはない。よって、通信中のマルウエア９の挙動を適切に観測することができる。

マルウエア９によって、接続可能なホストの探索が開始すると、探索パケットを送信する毎にタイムアウトのカウントを開始する。通信中は、時刻の運針を通常に戻す。一方で、ノード管理テーブル４２ｂに登録されていないＩＰアドレスのノード（即ち、ネットワーク４に存在しないホスト）に対しては、ＡＰＩ制御部４１で正常終了がマルウエア９に通知される。

従って、本実施例の適用の無い場合では、ネットワーク４に存在しないノードに費やされていた観測時間を大幅に省略でき、高速に動態解析を行うことができる。

マルウエア本体のＤＬ感染の処理フェーズでは、マルウエア９がレスポンスの有ったノードへ、マルウエア本体をダウンロードして感染させる。ノードへのダウンロードの開始時にタイムアウトのカウントを開始する。通信中は、時刻の運針は通常に戻されるため、舞うウエア９の挙動を阻害することなく観測することができる。

結果として、本実施例では、時刻の運針を通常に戻したとしても、Ｃ＆Ｃサーバ接続、探索、そしてマルウエア本体のＤＬ感染の処理フェーズで行われる通信に係る合計時間を短縮することができる。

マルウエア９の時間の早さは、例えば、図２５に示すような実行速度の設定画面を制御端末２に表示させ、ユーザに設定させてもよい。

図２５は、実行速度の設定画面の例を示す図である。図２５において、設定画面Ｇ７０は、ユーザが時計の運針の進む速さを倍率で設定するための画面である。設定画面Ｇ７０では、実行速度の倍率の値を速度を速くする方向へ一列に配列した実行速度（倍率）軸を表示し、ユーザは、実行速度（倍率）軸の上の△マークをマウス等で操作することにより容易に所望の実行速度（倍率）を設定可能としている。

ユーザにより倍率を指定したらＯＫボタンを選択されると、時計調整指示部６１により時計間隔調整部８２へ指示が行われる。

また、設定画面Ｇ７０には、ユーザへの参照として、ＡＰＩログ、ファイルログ等の最大容量の値を表示するようにしても良い。

上述より、本実施例に係る動態解析装置１００では、以下を行う。
・サンドボックス８内で、マルウエア９を実行し、動態解析の観測時間を調整する。
・ＯＳの計時ＡＰＩ７２１とサンドボックス８内の計時とを比較して時刻の運針を速くするか、遅くするかを決定し、時刻の運針を調整する。又は、実行速度の設定画面を制御端末３に表示させ、ユーザに設定させてもよい。
・サンドボックス８でスチールするＡＰＩは、スチールＡＰＩ選択ＤＢ３１に登録されている情報に従って、ＡＰＩ制御部４１で、通常のＯＳカーネル７ｋが提供するＡＰＩを呼び出すか、サンドボックス８がＯＳカーネル７ｋのＡＰＩとして処理を実行する（スチールして処理を実行する）かを決定する。

また、
・外部との通信系のＡＰＩ（socket()、send()、recv()等）で通信ｆｄに対する要求は、通常のＯＳカーネル７ｋのＡＰＩをそのまま呼び出すことで、１倍速で実行し、通信の正常性保つ。この時、通信時の応答待ちを正常にするため時刻の運針を１倍速の運針にする。
・通信系のＡＰＩであっても、ｆｄの示す宛先が、ノード管理テーブル４２ｂに存在しない場合は、実際の通信を行わすＡＰＩ制御部４１で正常終了として復帰させることで、高速に処理させ、通信時間が処理の多くを示すマルウエア９の処理を高速化する。
・タイマ関連のＡＰＩ（計時ＡＰＩ７２１）は、通信中の呼び出し以外では、時計調整指示部６１が指定した運針で加減速した状態で、ＯＳカーネル７ｋの計時ＡＰＩ７２１を呼び出す。
・その他のＡＰＩ７３１の呼び出しに対しては、サンドボックス環境８側でスチールし実行制御して必要に応じて呼び出す。

このような仕組みにより、本実施例では、
・マルウエア９の処理時間の多くを占める、ネットワーク４上のノード探索を予め存在するノードを示すノード管理テーブル４２ｂを作成しておくことで、存在するノードに対しては、実際に探索に係る通信を行い、存在するノードの数より相当数となる存在しないノードに対しては、通信を行わずにＡＰＩ制御部４１で正常終了で復帰させることで、大幅に通信時間を短縮できる。
・また、実際に通信を行う際には、通信のタイムアウトのタイミングが変化しないように、通信中（通信ＡＰＩ７１１の呼び出し時）は、タイマの運針を通常の１倍速にすることで、通信が正常に行えるようになり、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）による通信において外部との通信においてレスポンスを適切に受信できないことによる通信エラーが発生しないようにできる。

従来の動態解析では、マルウエア９の処理では、通信処理が比較的多く全体の処理の高速化を実現することが困難であったが、本実施例では、マルウエア９の通信の特徴である比較的処理時間を要する探索活動に着目し、相手先となるノードがネットワーク４に存在しない場合は実際の通信を行わず、相手先のノードが存在する場合には１倍速で時刻の運針を進めることで、通信全体の高速化を実現できる。

また、マルウエア９の動態解析には現象の発現に時間を要する場合があるが、本実施例によれば、マルウエア９からの通信系のＡＰＩ呼び出し、及び、通信中のＡＰＩ呼び出し以外では、時計の運針を早くするため、効率的に動態解析を行うことができる。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータによって実行される動態解析方法であって、
プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶し、
前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を設定し、
前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する、
ことを特徴とする動態解析方法。
（付記２）
前記通信相手先のノードが存在しない場合、通信を行うことなく正常終了で復帰することを特徴とする付記１記載の動態解析方法。
（付記３）
前記通信以外のプログラムの利用に係るインタフェースの呼び出しを、該インタフェースに代わって受信し、
通信状態に応じて前記プログラムの実行時間を変更する
ことを特徴とする付記１又は２記載の動態解析方法。
（付記４）
前記インタフェースはソフトウェア割込処理に係るインタフェースであることを特徴とする付記３記載の動態解析方法。
（付記５）
前記インタフェースは時間取得処理に係るインタフェースであることを特徴とする付記３又は４記載の動態解析方法。
（付記６）
前記実行時間は、ユーザによって変更可能であることを特徴とする付記１乃至５のいずれか一項記載の動態解析方法。
（付記７）
プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶し、
前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を設定する処理と、
前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する処理と、
をコンピュータに実行させることを特徴とする動態解析プログラム。
（付記８）
プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶する通信先管理部と、
前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を変更する制御部と、
前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する通信処理部と、
を有することを特徴とする動態解析装置。

２ 回線
３ 制御端末
４ ネットワーク
６ ルータ
７ｋ ＯＳカーネル
７１１ 通信ＡＰＩ、 ７１２ 通信処理部
７２１ 時計ＡＰＩ、 ７２２ 時計処理部
７３１ その他のＡＰＩ、 ７３２ その他の処理部
８ サンドボックス環境
９ マルウエア
１１ ＣＰＵ
１２ 主記憶装置
１３ 補助記憶装置
１４ 入力装置
１５ 表示装置
１６ 出力装置
１７ 通信Ｉ／Ｆ
１８ ドライブ
１９ 記憶媒体
３１ スチールＡＰＩ選択ＤＢ
４１ ＡＰＩ制御部
４２ 通信宛先管理部
４２ａ 通信管理テーブル、 ４２ｂ ノード管理テーブル
４３ タイマ管理テーブル
５１、５２ ホスト
８０ 時計間隔調整部
８１１ タイマ割込ＡＰＩ、 ８１２ タイマ割込ＡＰＩ制御部
８２１ 時刻取得ＡＰＩ、 ８２２ 時刻取得ＡＰＩ制御部
８２ 時計間隔調整部
９１ サンドボックス実行ランチャー
１００ 動態解析サーバ
１３０ 記憶部

Claims (5)

1. コンピュータによって実行される動態解析方法であって、
   プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶し、
   前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を設定し、
   前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する、
   ことを特徴とする動態解析方法。
2. 前記通信相手先のノードが存在しない場合、通信を行うことなく正常終了で復帰することを特徴とする請求項１記載の動態解析方法。
3. 前記通信以外のプログラムの利用に係るインタフェースの呼び出しを、該インタフェースに代わって受信し、
   通信状態に応じて前記プログラムの実行時間を変更する
   ことを特徴とする請求項１又は２記載の動態解析方法。
4. プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶し、
   前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を設定する処理と、
   前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する処理と、
   をコンピュータに実行させることを特徴とする動態解析プログラム。
5. プログラムが格納された通信装置とネットワークを介して接続されたノードの情報を記憶部に記憶する通信先管理部と、
   前記記憶部を参照し、前記通信装置の通信相手先のノードの存在有無に応じて前記プログラムの実行時間を変更する制御部と、
   前記プログラムに従って、前記通信装置から前記ノードの探索にかかる通信を実行する通信処理部と、
   を有することを特徴とする動態解析装置。

Images