ソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法
【課題】攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減するソフトウェア動作モデル化装置を提供する。
【解決手段】ソフトウェア動作モデル化装置100は、スタック情報記録部120と、終端情報記録部150と、終端情報記録部150が記録した終端情報を用いて、スタック情報のコールスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成するスタック差分情報生成部130と、スタック差分情報から、当該ソフトウェアの動作モデルを生成するモデル生成部140とを備える。
【解決手段】ソフトウェア動作モデル化装置100は、スタック情報記録部120と、終端情報記録部150と、終端情報記録部150が記録した終端情報を用いて、スタック情報のコールスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成するスタック差分情報生成部130と、スタック差分情報から、当該ソフトウェアの動作モデルを生成するモデル生成部140とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法に関する。
【背景技術】
【０００２】
PCやワークステーション、サーバ、ルータ、携帯電話、PDAなど、すべての計算機は外部もしくは内部からの攻撃にさらされている。代表的な攻撃は、計算機上で実行されているソフトウェアの脆弱性を踏み台にしたものである。攻撃者は、ソフトウェアの脆弱性を利用した悪意のあるコードを計算機に送り込み、実行中のプロセスの制御を奪い、当該プロセスの権限を利用して不正操作をおこなう。
【０００３】
脆弱性を利用した攻撃、特に未知の攻撃を検知するために、ソフトウェアの正常な動作をモデル化し、ソフトウェア実行中にモデルからの乖離の有無を判定する異常検知システムがある。システムコールは、プロセスがカーネルにシステム上重要な処理を依頼する際に行う命令であり、攻撃者は、プロセスが依頼するシステムコールを用いて、システムに任意の行動をさせる。そのため、ソフトウェアの動作を監視する際にシステムコールの正当性を検証することが行われる（例えば、特許文献１、非特許文献１、非特許文献２参照。）。
【０００４】
特許文献１に記載の攻撃対策装置では、システムコール発行元の関数がメモリのコード領域に存在することを正常とし、ソフトウェア（タスク）から発行されたシステムコール要求を入力し、正当性検査機能へのジャンプアドレスを出力するシステムコールテーブルと、システムコール要求発行時にOSによって特定のメモリ領域に格納されるシステムコール呼び出し元の復帰アドレスから、システムコール要求の正当性を判定し判定結果を出力するとともに、不正なシステムコール要求と断定した場合、そのシステムコール要求を棄却する正当性検査機能部と、正当性検査機能部の不正システムコール要求判定結果を入力し、対策を講ずる攻撃対策機能部と、正当性検査機能部の正当システムコール要求判定結果を入力して呼び出され、命令を実行するシステムコールとを備える。
【０００５】
非特許文献１に記載の攻撃検知システムでは、システムコールの正当性を検証するために、コールスタックの状況（スタックに積まれた復帰アドレスの列）を利用する。このシステムでは、まずソフトウェアを事前に実行し、得られた結果からモデルを学習する。プログラム実行中にシステムコール発生時のコールスタックの状況を取得し、システムコール発生時のプログラムカウンタとともに記録したVirtual Stack Listを生成し、又、現在のVirtual Stack Listと一つ前のVirtual Stack Listとの差分情報、すなわち比較対象のコールスタックの状況のスタック最下位より比較検証を順次行い異なる復帰アドレスを検出してから以降の復帰アドレスの列（Virtual Path）を生成する。生成されたVirtual Stack ListとVirtual Pathからそれぞれハッシュテーブルを生成し、そのテーブルをソフトウェアのモデルとして利用する。ソフトウェアの動作を検証する際には、ソフトウェア実行中に、Virtual Stack ListとVirtual Pathを生成し、モデルであるハッシュテーブルとのマッチングを行い、合致していればシステムコール要求に対し許可をし、合致しなければ、異常であると判定する。
【０００６】
非特許文献２に記載の攻撃検知システムでは、システムコールの正当性を検証するために、コールスタックの状況（スタックに積まれた復帰アドレスの列）を利用する。このシステムでは、監視対象ソフトウェアのバイナリコードを解析することによって、関数定義と、関数定義のオートマトンを生成する。このオートマトンは関数ごとに作られ、ソフトウェアの制御フローを監視するために用いられる。節点は、（１）関数の入り口、（２）関数の出口、（３）関数の呼び出しのいずれかとして定義されている。監視対象ソフトウェアの実行中、このシステムは、システムコールが発行されるたびに当該ソフトウェアを停止させ、その時点のコールスタックの状況を調べる。そして、復帰アドレス列から、呼び出されている関数のリスト（スタックバックトレースと呼ぶ）をつくる。そして、iを自然数とすると、i-1番目のスタックバックトレースと、i番目のスタックバックトレースを比較し、前者から後者に至る制御フローがモデル（オートマトン）に存在しているか否かを検証する。
【０００７】
LinuxをはじめとするOSにおいては、通常システムコールがWrapper関数を介して発行される。Wrapper関数はコード領域に存在しているため、システムコール発行元の関数は常にコード領域に存在する。又、攻撃として主流であるReturn-to-libc攻撃の場合、攻撃者はlibcへ復帰させて任意のシステムコールを発行する。以上の状況を考えると、システムコール発行元の関数のアドレスがコード領域にあることで正当とみなしてしまう特許文献１記載の攻撃対策装置では、検知できない攻撃が存在する。又、非特許文献１、非特許文献２記載の攻撃検知システムは、コールスタックに積まれた復帰アドレスの列を用いて検証をしているため、特許文献１記載の攻撃対策装置よりも詳細なモデル化を行っているといえる。そのため、攻撃見逃しを特許文献１よりも低減している。
【特許文献１】特開２００４−１２６８５４号公報
【非特許文献１】H.Fengら, “Anomaly Detection Using Call Stack Information”, The proc. of IEEE Symposium on Security and Privacy 2003, pp.62.
【非特許文献２】阿部ら，“静的解析に基づく侵入検知システムの最適化”，情報処理学会論文誌：コンピューティングシステム，vol.45，No.SIG3 (ACS 5)，pp.11-20
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１、非特許文献１ともに、ソフトウェアの動作をプログラム実行中に検証することを前提としているが、携帯電話など処理能力の低い計算機において、動作を検証するシステムを搭載するためには、限られた資源での処理の高速化、使用メモリ量の抑制が重要となる。
【０００９】
特に、非特許文献１では、精度を向上させるために、コールスタックの状況をモデルに含めており、検証の際にシステムコール発行のタイミングでコールスタックの状況を都度取得する必要がある。コールスタックの状況を取得するためには、スタックポインタ（SP）、ベースポインタ（BP）を利用してコールスタック内を探索し、スタックフレームを識別するスタックフレーム情報（位置、復帰アドレス、カナリなど）を順次取得する必要があるが、コールスタックはメモリ上に展開されているので、低速なメモリアクセスが頻繁に起き、時間オーバーヘッドが高い。
【００１０】
又、特に、非特許文献２では、精度向上のために、コールスタックの状況を監視しているが、スタックバックトレースにリストアップされた関数ごとにモデルを読み込み、制御フローの検証を行う必要がある。監視の速度を高速にするためには、読み込んだモデルをLRUアルゴリズムによってキャッシングすることが考えられるが、組み込み機器ではメモリ量が限られてしまうため、結果的には使用されないかもしれないモデルをメモリにおいておくことは、使用メモリ量を圧迫させてしまい、監視対象ソフトウェアの処理を著しく悪化させてしまう可能性がある。
【００１１】
そこで、本発明は、上記の問題に鑑み、攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減するソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するため、本発明の第１の特徴は、（ａ）ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するスタック情報記録部と、（ｂ）iを自然数とし、スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とを、コールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録する終端情報記録部と、（ｃ）終端情報記録部が記録した終端情報を用いて、スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成する第１のスタック差分情報生成部と、（ｄ）スタック差分情報から、当該ソフトウェアの動作モデルを生成するモデル生成部とを備えるソフトウェア動作モデル化装置であることを要旨とする。
【００１３】
第１の特徴に係るソフトウェア動作モデル化装置によると、監視の際にコールスタックの探索を中断する箇所を本来の終端情報の位置（場合によってはその近傍）に設定するための終端情報をソフトウェア毎に記録することができる。又、監視の際に，終端情報を用いてコールスタックの探索を中断する場合でも利用可能なモデルを生成することができる。このため、第１の特徴に係るソフトウェア動作モデル化装置によると、攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減することができる。
【００１４】
又、第１の特徴に係るソフトウェア動作モデル化装置において、終端情報記録部は、特定のイベントの識別子と終端情報の共起頻度の高い終端情報を、特定のイベントの識別子とともに記録し、スタック差分情報生成部は、終端情報記録部が記録した終端情報から、特定のイベントの識別子を利用して、スタック差分情報の生成に用いる終端情報を取得してもよい。
【００１５】
このソフトウェア動作モデル化装置によると、特定のイベント（システムコールなど）との共起関係の強い終端情報を記録することで、監視の際に、特定のイベントごとに特化した終端情報を利用することができる。
【００１６】
又、第１の特徴に係るソフトウェア動作モデル化装置において、終端情報記録部は、スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録してもよい。
【００１７】
このソフトウェア動作モデル化装置によると、記録する終端情報と本来の終端情報との差（コールスタック内での位置の違い）を小さく保ったまま、記録する終端情報の数を少なくすることができる。
【００１８】
更に、終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間の長さを把握し、期間が長いスタックフレーム情報を終端情報として記録してもよい。
【００１９】
又、第１の特徴に係るソフトウェア動作モデル化装置において、モデル生成部によって生成された、監視対象となるソフトウェアの動作モデルを取得するモデル取得部と、終端情報記録部によって記録された終端情報を取得する終端情報取得部と、コールスタックを検索している際に、終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成する第２のスタック差分情報生成部と、スタック差分情報生成部が生成したスタック差分情報と、モデル取得部が取得した動作モデルとの乖離を判定する動作監視部とを更に備えてもよい。
【００２０】
このソフトウェア動作モデル化装置によると、同一の端末上でのモデル化、監視の実現に加え、終端情報を利用した効率のよい、コールスタックの探索を実現できる。
【００２１】
又、第１の特徴に係るソフトウェア動作モデル化装置において、スタックフレーム情報は、復帰アドレスであってもよい。
【００２２】
このソフトウェア動作モデル化装置によると、コールスタックを修正することなく、スタックフレームを識別する情報を取得することができる。
【００２３】
本発明の第２の特徴は、（ａ）監視対象ソフトウェアが発行した特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを関数モデルとしたとき、監視対象のソフトウェアが発行した特定のイベントごとに、前記関数モデルを取得するモデル取得部と、（ｂ）ソフトウェアの実行環境において、監視対象のソフトウェアに適した終端情報を取得する終端情報取得部と、（ｃ）当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、（ｄ）スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するスタック差分情報生成部と、（ｅ）スタック差分情報生成部が生成したスタック差分情報と、モデル取得部が取得した動作モデルとの乖離を判定する動作監視部とを備えるソフトウェア動作監視装置であることを要旨とする。
【００２４】
第２の特徴に係るソフトウェア動作監視装置によると、学習時に得られた終端情報を利用して、コールスタックの探索を中断でき、監視にかかるオーバーヘッドを軽減することができる。特に、終端情報取得部は、事前に取得した特定のイベントの識別子と終端情報の共起頻度の高い終端情報を特定のイベントの識別子とともに記録した情報を、特定のイベントの識別子に基づいて取得することで，コールスタック探索の中断の確認において、特定のイベントとの共起関係の強い終端情報をつかうことができるので、特定のイベントに適した中断を行うことができる。
【００２５】
又、第２の特徴に係るソフトウェア動作監視装置は、モデル取得部によって記録された関数モデルを廃棄するモデル廃棄部を更に備え、モデル取得部は、事前に監視対象ソフトウェアのコードから関数ごとに生成した、関数相互の呼び出しの関係を示す関数モデルを取得し、動作監視部は、スタック差分情報生成部によって生成されたスタック差分情報と、モデル取得部が取得した関数モデルとの乖離を判定し、スタック情報取得部は，コールスタックからスタックフレーム情報を取得する際に、終端情報と一致するスタックフレーム情報を検知した場合に、スタックフレーム情報の取得を中断し、その場合、モデル廃棄部は、モデル取得部が以前のスタック差分情報の監視のために記録した関数モデルを廃棄してもよい。
【００２６】
このソフトウェア動作監視装置によると、メモリ上に残存した不要な関数モデルをメモリから排除することができ、使用メモリ量を抑えることができる。
【００２７】
関数モデルの廃棄は、次のシステムコール発生時のスタック差分情報の検証の際に必要となる関数モデルの廃棄をしてしまう恐れがある。そこで、終端情報取得部は、事前に取得したスタック情報の時系列から、ある期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することで、検証の際に、ある期間利用されない関数モデルのみを廃棄することができるので、終端情報に基づく関数モデルの廃棄に伴うリスクを軽減することができる。
【００２８】
又、第２の特徴に係るソフトウェア動作監視装置において、終端情報取得部は、スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得してもよい。
【００２９】
このソフトウェア動作監視装置によると、終端情報の確認結果をキャッシュに保存するなどして効率化を図ることができる。
【００３０】
更に、終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間が長いスタックフレーム情報を終端情報として記録した情報を取得してもよい。
【００３１】
又、第２の特徴に係るソフトウェア動作監視装置において、モデル廃棄部は、システムの現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えてもよい。
【００３２】
メモリの空き状況によっては、関数モデルを廃棄せずにLRUアルゴリズムなどでキャッシングしたほうが、時間オーバーヘッドを軽減できる可能性がある。このソフトウェア動作監視装置によると、モデル廃棄部は、現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えることで、必要な場合にのみ関数モデルを廃棄できるため、リスクを軽減することができる。
【００３３】
又、第２の特徴に係るソフトウェア動作監視装置は、関数モデルを記憶するモデル記憶部を更に備え、モデル取得部は、取得した関数モデルに識別子をつけてモデル記憶に記録し、モデル廃棄部は、識別子で廃棄する関数モデルを指定する廃棄命令をモデル記憶部に伝えてもよい。
【００３４】
このソフトウェア動作監視装置によると、廃棄する関数モデルを特定することができる。
【００３５】
本発明の第３の特徴は、（ａ）ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するステップと、（ｂ）iを自然数とし、スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とをコールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録するステップと、（ｃ）終端情報記録部が記録した終端情報を用いて、スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成するステップと、（ｄ）スタック差分情報から、当該ソフトウェアの動作モデルを生成するステップとを含むソフトウェア動作モデル化方法であることを要旨とする。
【００３６】
又、本発明の第４の特徴は、（ａ）監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを取得するステップと、（ｂ）ソフトウェアの実行環境において、監視対象のソフトウェアに適した終端情報を取得するステップと、（ｃ）当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報をコールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するステップと、（ｄ）スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するステップと、（ｅ）スタック差分情報生成部が生成したスタック差分情報と、モデル取得部が取得した動作モデルとの乖離を判定するステップとを含むソフトウェア動作監視方法であることを要旨とする。
【発明の効果】
【００３７】
本発明によると、攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減するソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法を提供することができる。
【発明を実施するための最良の形態】
【００３８】
次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。ただし、図面は模式的なものであることに留意すべきである。
【００３９】
＜第１の実施の形態＞
（ソフトウェア動作モデル化装置）
第1の実施形態に係るソフトウェア動作モデル化装置100は、図１に示すように、監視対象プロセス10、監視対象プロセスが利用するメモリ空間20、任意でしきい値30を用いて、監視対象プロセス10の正常な動作を表すモデル情報50と、終端情報40を生成し、出力する。ここで、「監視対象プロセス10」とは、ソフトウェアの動作を監視すべきソフトウェアの実行形態をいう。当該監視対象プロセス10の監視指示は、ユーザによって外部から与えられてもよく、ソフトウェア配信者がソフトウェアに付与したメタ情報によって与えられてもよい。
【００４０】
ソフトウェア動作モデル化装置100は、システムコール情報取得部110と、スタック情報記録部120と、スタック差分情報生成部130と、モデル生成部140と、終端情報記録部150とを備える。
【００４１】
システムコール情報取得部110は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報記録部120がスタック情報を記録するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール番号などを含むシステムコール情報115を取得する。システムコール情報取得部110は、デバッグツールで実現できるが、例えば，Linuxに実装されているptraceを利用することで、容易に実現できる。
【００４２】
なお、第1の実施形態に係るソフトウェア動作モデル化装置100では、特定のイベントとして監視対象プロセス10が発行するシステムコールとしているが、本発明はそれのみにこだわる必要はない。システムコール以外の特定のイベントとは、たとえば、jmp命令などがあげられる。たとえば、Linuxに実装されているptraceを利用し、1ステップ実行を行うことで、インストラクションを取得することが可能なので、ソフトウェア動作モデル化装置がjmp命令を検知できる。
【００４３】
スタック情報記録部120は、システムコール情報取得部110がシステムコールを検知した時点でのコールスタックの状況25を、監視対象プロセスが利用するメモリ空間20から取得する。ここで、「コールスタックの状況」とは、スタックフレームの積まれた状態をいう。コールスタックの状況から、スタックフレームを識別する情報を取得する。ここで、「スタックフレームを識別する情報」とは、例えば、復帰アドレスやカナリなどがあげられる。カナリは、バッファーオーバーフロー脆弱性をついたスタックスマッシング攻撃を防止するために用いられる、スタックフレームごとに挿入される値のことである。カナリが、スタックフレームが生成された時点と比較して異なる値を示した場合、スタックフレームがスタックスマッシング攻撃によって破壊されたとして検知することができる。このカナリは、攻撃者が推定できると意味を成さないので、乱数を利用することが多いが、このカナリに、スタックフレームを識別できる情報を含めることも可能である。そのようにカナリを設計することで、カナリを取得すれば、スタックフレームを識別することができる。
【００４４】
第１の実施形態では、復帰アドレスを用いてスタックフレームを識別するとして詳しく説明する。すなわち、コールスタックの状況から復帰アドレスのみを抽出して、スタック情報として出力する。抽出の仕方はいろいろあるが、x86やARMなどのコールスタックでは、復帰アドレスはスタックフレームの最上位（底部の逆）に存在しているので、例えば、レジスタに保持されたスタックポインタとベースポインタを利用して、ベースポインタの直下の値を取得することで実現できる。スタック情報は、スタック情報記録部120によってシステムコールが発行されたタイミングで、時系列順に記録される。
【００４５】
終端情報記録部150は、スタック情報記録部120によって記録されたi-1番目のスタック情報と、i番目のスタック情報とを底から順に比較し、コールスタックの位置と復帰アドレスが一致している部分を一致部分、異なる復帰アドレスを検知してから以降の部分を不一致部分とし、一致部分と不一致部分の境界を作る。この不一致部分の端に位置する復帰アドレスを「終端情報」という。
【００４６】
図2は、スタック情報、一致部分、不一致部分、スタック差分情報、終端情報の例を示している。図2(a)に示すように、i-1番目のスタック情報と、i番目のスタック情報とを比較すると、一致部分が図2（b）に示すように、不一致部分が図3（c）に示すようになる。一致部分と不一致部分を分かつ復帰アドレスは“x”であるので、図3（e）に示すように、終端情報はxとなる。又、モデル化に利用するスタック差分情報とは、図3（d）に示すように、不一致部分を連結した情報である。スタック差分情報を生成する際には、スタック情報から一致部分を除外し、不一致部分を抽出する処理を行う。この場合、スタック情報は底から検証する必要があるが、コールスタックの探索においては、スタックポインタがスタック上位（底と逆）に存在しているため、スタック上位から底に向かって探索が行われる。そのため、コールスタックに積まれたすべての復帰アドレスを取得する必要があるといえる。しかし、この終端情報は“除外すべき情報”と“抽出すべき情報”の境界に存在しているので、この終端情報を事前にリストアップしておき、コールスタックの探索時に利用することで、すべての復帰アドレスを取得することなく中断できる。
【００４７】
終端情報記録部150は、スタック情報記録部120が記録したスタック情報125Aから、任意でしきい値30を利用して、終端情報40を記録する。終端情報は、記録したスタック情報の中に多く存在するので、そのすべてをリストアップしてもよいが、コールスタックの探索時に有用な情報を抽出してもよい。例えば、スタック情報はシステムコール時に生成されたので、システムコール識別子と終端情報の共起関係を把握し、共起頻度の高い終端情報を記録することがあげられる。図3（a）は、スタック情報記録部120が記録したスタック情報の例である。システムコール識別子と終端情報の共起頻度を調査し、システムコールごとに共起頻度の高い終端情報を抽出する。図3（b）は、そうして抽出された終端情報の例である。
【００４８】
第１の実施形態では、任意のしきい値以上の長さをもった期間、コールスタックの底からみて定位置に存在する終端情報を抽出する例を詳細に説明する。main関数を代表とするプログラム（あるいはモジュール）を統括する関数などは、コールスタックの定位置に存在する期間が長く、その位置よりも下位にある復帰アドレスはi番目のスタック情報とi-1番目のスタック情報で一致していることが多い。そのため、長い間定位置に存在する復帰アドレスは本来の終端情報である可能性が高い。このことから、終端情報は、一致部分と不一致部分の境界に存在する復帰アドレスでなくてもよく、コールスタックの定位置に存在する期間が長い復帰アドレスを終端情報として抽出してもよい。
【００４９】
図4（a）は、スタック情報記録部120が記録したスタック情報の例である。スタック情報の中で、mainやX、aは、長い間定位置に存在した復帰アドレスである。このように定位置に連続して存在する復帰アドレスを抽出する。ここで、しきい値をあたえ、しきい値以上の長さをもつ復帰アドレスを終端情報として抽出してもよい。図4（b）では、しきい値が3である場合で、mainとXが終端情報として抽出される。
【００５０】
ソフトウェア動作モデル化装置100は、終端情報記録部150により得た終端情報40を出力し、更に、終端情報155を用いてスタック差分情報を生成する。
【００５１】
スタック差分情報生成部130は、スタック情報と、終端情報40と、システムコール情報115とを入力として、スタック差分情報135を生成する。スタック差分情報生成部130では、i-1番目のスタック情報とi番目のスタック情報から不一致部分を抽出し、得られた不一致部分を連結させて、スタック差分情報を生成する。
【００５２】
モデル生成部140は、スタック差分情報135から監視対象プロセス10の動作モデルを生成する。例えば、非特許文献１のようにスタック差分情報135のハッシュ値をとる、システムコール識別子とスタック差分情報との相関規則を導出する等である。
【００５３】
（ソフトウェア動作モデル化方法）
次に、第１の実施形態に係るソフトウェア動作モデル化方法について、図５を参照して説明する。
【００５４】
まず、システムコール情報取得部110は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報記録部120がスタック情報を記録するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール番号などを含むシステムコール情報115を取得する（ステップS10）。
【００５５】
次に、スタック情報記録部120は、システムコール情報取得部110がシステムコールを検知した時点でのコールスタックの状況25を、監視対象プロセスが利用するメモリ空間20から取得する（ステップS11）。
【００５６】
次に、終端情報記録部150は、スタック情報記録部120が記録したスタック情報125Aから、任意でしきい値30を利用して、終端情報40を記録する（ステップS12）。尚、終端情報記録部150の動作例については、後に詳述する。
【００５７】
次に、スタック差分情報生成部130は、スタック情報125と、終端情報40と、システムコール情報115とを入力として、スタック差分情報135を生成する（ステップS13）。尚、スタック差分情報生成部130の動作例については、後に詳述する。
【００５８】
次に、モデル生成部140は、スタック差分情報135から監視対象プロセス10の動作モデルを生成する（ステップS14）。
【００５９】
次に、ステップS12の動作例について、図6を参照して詳細に説明する。
【００６０】
まず、終端情報記録部150は、各終端情報の定位置に存在する期間の長さ（以下において、「連続数」という。）をカウントするためのListAと、連続数をもった終端情報を保存するListBを利用する。図7(a)、(b)は、それぞれListA、ListBの例である。ListAは、終端情報とコールスタック底から数えた位置、連続数、スタック情報を検査した後に当該終端情報がカウントアップされたか否かを判定するためのflagから構成される。ListBは、終端情報と、連続数で構成される。
【００６１】
図6のとおり、終端情報記録部150は、まずListAとListBを初期化、すなわちアイテムがまったくない状態にする（ステップS100）。次に、スタック情報を読み込む（ステップS110）。次に、読み込んだスタック情報から、コールスタック底から順次復帰アドレスを読み込む（ステップS120）。この読み込みでは、前回取得したスタック情報との比較を次に行うので、前回取得したスタック情報で、今読み込んだ復帰アドレスの位置と同じ位置に存在する復帰アドレスを読み込む。
【００６２】
次に、読み込んだ復帰アドレスどうしを比較し、不一致であるか否かを検証する（ステップS130）。不一致であった場合、前回のループで読み込んだ復帰アドレスを終端情報とし、ListAを更新する（ステップS140）。ListAの更新では、終端情報がListAに存在しているか否かを検証し、存在していなかったらListAに当該終端情報、位置、連続数=0、flag=0を追加する。
【００６３】
ステップS130において、一致であった場合、もしくは、ステップS140の後に、復帰アドレスあるいは終端情報かつ同じ位置である終端情報がListAに存在しているか否かを検証する（ステップS150）。存在していれば、当該終端情報の連続数を＋１し（ステップS160）、flagを1にする（ステップS170）。
【００６４】
このステップS120からS170までをスタック情報が終了するまで続ける。次に、ListAのアイテムを順次読み込む（ステップS180）。読み込んだアイテムのflagが1であるか否かを検証する（ステップS190）。1でない場合、連続がとまったことになるので、当該終端情報の連続数が確定したことになる。確定した連続数と終端情報を元に、ListBを更新する（ステップS220）。又、当該終端情報の連続数をクリアする（ステップS230）。ステップS190において1であった場合、もしくは、ステップS230の後に、flagを0にする（ステップS200）。
【００６５】
このステップS180からS200までをListAが終わるまで続ける。さらに、ステップS110からステップS200までをスタック情報読み込み終了まで続ける。
【００６６】
こうして得られたListBを、連続数を元に並べ替える（ステップS210）。次に、ListBのアイテムを順次読み込む（ステップS240）。しきい値と連続数を比較し（ステップS250）、しきい値よりも連続数のほうが大きい場合、終端情報を記録する（ステップS260）。このステップS240からS260までをListBが終了するまで続ける。
【００６７】
なお、こうして得た終端情報と、一致部分、不一致部分をわける終端情報との位置の差を誤差情報として、例えば、終端情報とともに外部記録に記録してもよい。
【００６８】
次に、ステップS13での不一致部分抽出ステップの動作例について、図8を参照して詳細に説明する。
【００６９】
まず、スタック差分情報生成部130は、終端情報を取得する（ステップS300）。次に、スタック情報より復帰アドレスを取得する（ステップS310）。次に、終端情報と復帰アドレスが一致しているか否かを検証し（ステップS320）、一致していた場合は、不一致部分抽出ステップを終了する。不一致の場合は、ステップS320を終端情報が終了するまで続ける。終端情報が終わった場合は、ステップS310で取得した復帰アドレスは不一致部分のアイテムであると判断し、記録する（ステップS330）。ステップS310〜S330をスタック情報が終了するまで続ける。
【００７０】
スタック差分情報生成部130は、こうして得られたi番目の不一致部分と前回得たi-1番目の不一致部分とを結合する。結合のさせ方について例で示す。図3（d）に示すスタック差分情報は、図3（c）の不一致部分を結合する際に、システムコールi番目のスタック情報から得た不一致部分の順序を逆にして結合している。これは非特許文献１に習ってそうしているが、順序を逆にしなくてもよい。というのも、モデルをスタック差分情報上の復帰アドレスとシステムコール識別子との相関規則で生成する場合、順序は意味をなさないからである。スタック差分情報は、システムコール識別子とともに出力され、モデル生成部140に伝えられる。
【００７１】
なお、誤差情報を終端情報記録部150で記録している場合、図7のステップS320において、一致であった場合に、すぐに終了せずに、誤差情報分の復帰アドレスを追加で取得し検査してもよい。このようにすることで、本来の終端情報からの乖離の距離が短くなるため、精度のよいモデルを生成することができる。
【００７２】
（ソフトウェア動作監視装置）
次に、第１の実施形態に係る、監視対象プロセス10の動作の正常異常判定を行うソフトウェア動作監視装置について、図9を用いて説明する。
【００７３】
第１の実施形態に係るソフトウェア動作監視装置500は、図9に示すように、監視対象プロセスが利用するメモリ空間20、終端情報40、モデル情報50、ソフトウェア識別子70を利用して、判定結果60を出力する。
【００７４】
ソフトウェア動作監視装置500は、システムコール情報取得部510と、スタック情報取得部520と、終端情報取得部550と、スタック差分情報生成部530と、動作監視部540と、モデル取得部560とを備える。
【００７５】
ソフトウェア動作監視装置500は、ソフトウェアがロードされると、ソフトウェア識別子70とモデル情報50から、監視対象プロセス10の監視に適したモデル565を取得するモデル取得部560を起動させる。
【００７６】
システムコール情報取得部510は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報取得部520がスタック情報の取得を終了するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール情報を取得する。システムコール情報取得部510はLinuxに実装されているptraceを利用することで、容易に実現できる。
【００７７】
終端情報取得部550は、ソフトウェア識別子70と、終端情報40から、監視対象プロセスに適した終端情報555を取得し、スタック情報取得手部520に伝える。終端情報がシステムコール識別子ごとに記録されている場合、終端情報取得部550にさらにシステムコール情報515Aを入力して、監視対象プロセス10によって発行されたシステムコールごとに終端情報を選択する。
【００７８】
スタック情報取得部520は、監視対象プロセスが利用するメモリ空間20からコールスタックの状況25を取得し、更に、終端情報555を利用し、スタック情報525を生成する。スタック情報取得部520は、コールスタックの状況から、スタックフレームを識別する情報を取得する。
【００７９】
第１の実施形態では、復帰アドレスを用いてスタックフレームを識別するとして詳しく説明する。すなわち、スタック情報取得部520は、コールスタックの状況25から、復帰アドレスを取得する。更に、スタック情報取得部520は、終端情報555を利用して、スタックフレームを識別する情報（第１の実施形態では復帰アドレス）の取得を中断する。
【００８０】
図10は、終端情報を利用してスタック情報取得を中断する例を示している。図10（a）は、終端情報取得部550が取得した終端情報の例である。又、図10（b）は、ある時点でのコールスタックの状況の例である。システムコールが発行され、図10（b）上に示すコールスタックの状況から、図10(b)下に示すコールスタックの状況に遷移が起こった場合を考える。なお、コールスタックの状況には復帰アドレスだけでなく関数に渡される引数などが存在するが、説明を簡単にするために、復帰アドレスのみを示している。図10（b）上に示すコールスタックの状況から、スタック上位より復帰アドレスを順次取得していく。取得しながら、終端情報と比較をしていくと、終端情報と一致するxを検知する。この時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のs,r,p,q）。図10（b）下に示すコールスタックの状況からも同様に、終端情報と一致するxを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のh,g,f）。こうして得られたスタック情報は、次ステップであるスタック差分情報生成部530によって結合されスタック差分情報となる（図10(b)右）。
【００８１】
又、図11は、終端情報を利用してスタック情報取得を中断する別の例を示している。図11（a）は、終端情報取得部550が取得した終端情報の例である。図10と異なり、システムコール識別子と対になっている。スタック情報取得部520は、システムコール情報取得部510が取得したシステムコール番号を用いて、システムコールにあわせて終端情報を切り替える。図11（b）は、ある時点でのコールスタックの状況の例である。システムコールが発行され、図11（b）上に示すコールスタックの状況から、図11（b）下に示すコールスタックの状況に遷移が起こった場合を考える。なお、コールスタックの状況には復帰アドレスだけでなく関数に渡される引数などが存在するが、説明を簡単にするために、復帰アドレスのみを示している。図11（b）上のコールスタック状況は、システムコール番号4が発行されて得られた情報であることから、終端情報は、xとなる。コールスタックの上位から順次復帰アドレスを取得し、終端情報と比較し、終端情報xと一致する復帰アドレスを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のs,r,p,q）。同様に、図11（b）下のコールスタック状況の場合、システムコール番号6が発行されて得られた情報であることから、mainが終端情報となる。コールスタックの上位から順次復帰アドレスを取得し、終端情報と比較し、終端情報mainと一致する復帰アドレスを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のh,g,f,x,y）。こうして得られたスタック情報は、次ステップであるスタック差分情報生成部530によって結合され、スタック差分情報となる（図10（b）右）。
【００８２】
スタック差分情報生成部530は、スタック情報525と、システムコール情報515Bを入力として、スタック差分情報335を生成する。スタック差分情報生成部530では、i-1番目のスタック情報とi番目のスタック情報から不一致部分を抽出し、得られた不一致部分を連結させて、スタック差分情報を生成する。
【００８３】
モデル取得部560は、監視対象プロセス10が発行した特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを関数モデルとしたとき、監視対象プロセス10が発行したシステムコールごとに、関数モデルを取得する。
【００８４】
動作監視部540は、スタック差分情報生成部520が生成したスタック差分情報535と、モデル取得部560が取得した動作モデル530との乖離を判定し、判定結果60として出力する。
【００８５】
（ソフトウェア動作監視方法）
次に、第１の実施形態に係るソフトウェア動作監視方法について、図12を参照して説明する。
【００８６】
まず、システムコール情報取得部510は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報取得部520がスタック情報の取得を終了するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール情報を取得する（ステップS20）。
【００８７】
次に、終端情報取得部550は、ソフトウェア識別子70と、終端情報40から、監視対象プロセスに適した終端情報555を取得し、スタック情報取得手部520に伝える（ステップS21）。
【００８８】
次に、スタック情報取得部520は、監視対象プロセスが利用するメモリ空間20からコールスタックの状況25を取得し、更に、終端情報555を利用し、スタック情報525を取得する（ステップS22）。尚、スタック差分情報取得部520の動作例については、後に詳述する。
【００８９】
次に、スタック差分情報生成部530は、スタック情報525と、システムコール情報515Bを入力として、スタック差分情報335を生成する（ステップS23）。
【００９０】
一方、ソフトウェアがロードされると、モデル取得部560は、ソフトウェア識別子70とモデル情報50から、監視対象プロセス10の監視に適したモデル565を取得する（ステップS24）。
【００９１】
次に、動作監視部540は、スタック差分情報生成部520が生成したスタック差分情報535と、モデル取得部560が取得した動作モデル530との乖離を判定し、判定結果60として出力する（ステップS25）。
【００９２】
次に、ステップS22の動作例について、図13を参照して詳細に説明する。
【００９３】
まず、スタック情報取得部520は、終端情報取得部550から終端情報を得る（ステップS500）。次に、コールスタックの状況25より、順次スタックフレームを取得し（ステップS510）、当該スタックフレームの復帰アドレスを取得する（ステップS520）。
【００９４】
次に、スタック情報取得部520は、終端情報を順次読み込み、ステップS520で取得した復帰アドレスと終端情報とを比較する（ステップS530）。ステップS530は、終端情報が終わるまで、もしくは、復帰アドレスと終端情報との一致が確認されるまで続ける。終端情報が終わるまで一致が確認されなかった場合は、復帰アドレスをスタック情報として記録し（ステップS540）、スタックフレームが終わるまで、ステップS510からステップS540までを繰り返す。
【００９５】
ステップS530で一致が確認された場合は、ループを抜け、スタック情報取得処理を終了する。なお、終端情報に誤差情報が付与されている場合は、ステップS530で一致を確認した後に、誤差情報が示す分まで復帰アドレスを取得するステップを追加してもよい。
【００９６】
（作用及び効果）
第１の実施形態に係るソフトウェア動作モデル化装置は、記録した終端情報を抽出し、終端情報に基づいて、スタック情報からソフトウェアの動作モデルを生成する。
【００９７】
このため、第１の実施形態に係るソフトウェア動作モデル化装置によると、監視の際にコールスタックの探索を中断する箇所を本来の終端情報の位置（場合によってはその近傍）に設定するための終端情報をソフトウェア毎に記録することができる。又、監視の際に、終端情報を用いてコールスタックの探索を中断する場合でも利用可能なモデルを生成することができる。
【００９８】
特に、特定のイベント（システムコールなど）との共起関係の強い終端情報を記録することで、監視の際に、特定のイベントごとに特化した終端情報を利用することができる。
【００９９】
又特に、スタック情報記録部が記録したスタック情報の時系列から、ある期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録することで，記録する終端情報と本来の終端情報との差（コールスタック内での位置の違い）を小さく保ったまま、記録する終端情報の数を少なくすることができる。
【０１００】
又、特に、スタックフレーム情報は、復帰アドレスであることを特徴とすることで、コールスタックを修正することなく、スタックフレームを識別する情報を取得することができる。
【０１０１】
又、第１の実施形態に係るソフトウェア監視装置は、コールスタック検索の際に、終端情報とマッチする復帰アドレスの検知を契機に、コールスタックの探索を中断し、その時点までで得られたスタック情報で動作検証を行う。
【０１０２】
このため、第１の実施形態に係るソフトウェア監視装置によると、監視対象ソフトウェアの動作をソフトウェア実行中に監視する際、学習時に得られた終端情報を利用して、コールスタックの探索を中断でき，監視にかかるオーバーヘッドを軽減することができる。
【０１０３】
特に、終端情報取得部は、事前に取得した特定のイベントの識別子と終端情報の共起頻度の高い終端情報を特定のイベントの識別子とともに記録した情報を、特定のイベントの識別子に基づいて取得することで、コールスタック探索の中断の確認において，特定のイベントとの共起関係の強い終端情報をつかうことができるので、特定のイベントに適した中断を行うことができる。
【０１０４】
又、特に、終端情報取得部は、事前に取得したスタック情報の時系列から、ある期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することで，終端情報の確認結果をキャッシュに保存するなどして効率化を図ることができる。
【０１０５】
＜第２の実施形態＞
（ソフトウェア動作モデル化及びソフトウェア動作監視装置）
図14は、第２の実施形態に係るソフトウェア動作モデル化及びソフトウェア動作監視装置1000の構成例を示すブロック図である。
【０１０６】
ソフトウェア動作モデル化及びソフトウェア動作監視装置1000は、監視対象プロセス10の動作を表すモデル情報1055をモデル情報DB50に格納し、さらに、終端情報1085を終端情報DB30に格納する装置である。さらに、ソフトウェア動作監視装置1000は、監視対象プロセス10の動作の監視に適したモデル情報55、終端情報35を、モデル情報DB50、終端情報DB30からそれぞれ取得し、監視対象プロセス10の動作の検証を行い、検証結果60を出力する装置である。
【０１０７】
ソフトウェア動作モデル化及びソフトウェア動作監視装置1000は、システムコール情報取得部1010と、スタック情報記録部1020と、スタック情報取得部1030と、スタック差分情報生成部1040と、モデル生成部1050と、モデル取得部1060と、動作監視部1070と、終端情報記録部1080と、終端情報取得部1090とを備える。
【０１０８】
監視対象プロセス10の動作をモデル化する場合、ソフトウェア動作監視装置1000は、システムコール情報取得部1010、スタック情報記録部1020、スタック差分情報生成部1040、モデル生成部1050、終端情報記録部1080を起動する。それぞれの構成要素は、第１の実施形態に記載のソフトウェア動作モデル化装置100における、システムコール情報取得部110、スタック情報記録部120、スタック差分情報生成部130、モデル生成部140、終端情報記録部150と同様としてもよい。詳細は、第１の実施形態を参照されたい。
【０１０９】
監視対象プロセス10の動作を監視する場合、ソフトウェア動作監視装置1000は、システムコール取得部1010、スタック情報取得部1030、スタック差分情報生成部1040、モデル取得部1060、動作監視部1070、終端情報取得部1090を起動する。それぞれの構成要素は、第１の実施形態に記載のソフトウェア動作監視装置500における、システムコール情報取得部510、スタック情報取得部520、スタック差分情報生成部530、モデル取得部560、動作監視部540、終端情報取得部550と同様としてもよい。詳細は、第１の実施形態を参照されたい。
【０１１０】
（作用及び効果）
第２の実施形態に係るソフトウェア動作モデル化及びソフトウェア動作監視装置によると、同一の端末上でのモデル化、監視の実現に加え、終端情報を利用した効率のよいコールスタックの探索を実現できる。
【０１１１】
＜第３の実施形態＞
図15は、第3の実施形態に係るソフトウェア動作監視装置5100の構成例を示すブロック図である。
【０１１２】
ソフトウェア動作監視装置5100は、関数モデルをある期間記憶するモデル記憶部5180と、終端情報が格納された終端情報DB30と、関数モデルが格納された関数モデルDB50とに接続し、監視対象プロセス10の動作の正常/異常判定を行う装置であって、監視対象プロセスが利用するメモリ空間20、ソフトウェア識別子60、終端情報35、関数モデル55を利用して、判定した結果40を出力する。又、関数モデル5175をモデル記憶部5180に記録し、モデル記憶部5180に記録された関数モデル5185を取得して、廃棄命令5155を出力してモデル記憶部5180に記録された関数モデルをモデル記憶部5180から削除する。
【０１１３】
ソフトウェア動作監視装置5100は、システムコール発行検知部5110と、スタック情報取得部5120と、スタック差分情報生成部5130と、動作監視部5140と、モデル廃棄部5150と、終端情報取得部5160と、モデル取得部5170とを備える。
【０１１４】
システムコール発行検知部5110は、監視対象プロセス10がシステムコール15を発行したことを検知し、動作の検証がすむまで監視対象プロセス10を停止させ、検知情報5115をスタック情報取得部5120に伝える。検知情報5115は、スタック情報取得部5120を起動させるトリガとして利用すればよいので、例えば、スタック情報取得部5120の動作を管理するフラグがあったとして、そのビットを立てるとしてもよい。システムコール発行検知部5110は、例えば、Linux上のデバッグツールであるptraceを利用することで容易に実現できる。
【０１１５】
スタック情報取得部5120は、検知情報5115を受けると、監視対象プロセスが利用するメモリ空間20からコールスタックの状況25を取得し、さらに終端情報5165を利用し、スタック情報5125Aを生成する。生成したスタック情報5125Aはスタック差分情報生成部5130に伝えられる。スタック情報取得部5120は、コールスタックの状況25から、スタックフレームを探索し、スタックフレームを識別するスタックフレーム情報を順次取得する。スタックフレーム情報とは、例えば、復帰アドレスやカナリなどがあげられる。
【０１１６】
第３の実施形態では、復帰アドレスを用いてスタックフレームを識別するとして詳しく説明する。すなわち、スタック情報取得部5120は、コールスタックの状況25から各フレームに存在する復帰アドレスを順次取得する。抽出の仕方はいろいろあるが、x86やARMなどのコールスタックでは復帰アドレスはスタックフレームの最上位（底部の逆）に存在しているので、例えば、レジスタに保持されたスタックポインタとベースポインタを利用して、ベースポインタの直下の値を取得することで実現できる。スタック情報は、スタック情報記録部5120によってシステムコールが発行されたタイミングで、時系列順に記録される。又、スタック情報取得部5120は、終端情報5165（後に説明）によって復帰アドレス取得を中断し、終端到達情報5125Bをモデル廃棄部5150に伝えることを特徴とする。
【０１１７】
スタック差分情報生成部5130は、スタック情報5125Aを入力として、スタック差分情報、すなわち、pop情報5135A、push情報5135Bを生成する。スタック差分情報生成部5130では、システムコールi-1番目のスタック情報とシステムコールi番目のスタック情報から不一致部分を抽出し、得られた不一致部分を、pop情報、push情報として出力する。
【０１１８】
終端情報取得部5160は、終端情報DB30に記録されたi-1番目のスタック情報と、i番目のスタック情報とをコールスタックの底から順に比較し、コールスタックの位置と復帰アドレスが一致している部分を一致部分、異なる復帰アドレスを検知してから以降の部分を不一致部分とし、一致部分と不一致部分の境界である終端情報を取得する。図2は、スタック情報、一致部分、不一致部分、スタック差分情報、終端情報の例を示している。図2（a）で示すスタック情報を比較すると、一致部分が図2（b）、不一致部分が図2（c）となる。一致部分と不一致部分を分かつ復帰アドレスは“x”であるので、図2（e）のとおり、終端情報はxとなる。又、検証に利用するスタック差分情報とは、図2（d）のとおり、システムコールi番目の不一致部分のうち、システムコールi-1番目のスタック情報に存在した情報に終端情報を加えた情報をpop情報、システムコールi番目のスタック情報に存在した情報に終端情報を加えた情報をpush情報とすると、pop情報、push情報を総称した情報である。スタック差分情報を生成する際には、スタック情報から一致部分を除外し、不一致部分を抽出する処理を行う。この場合、スタック情報は底から検証する必要があるが、コールスタックの探索においては、スタックポインタがスタック上位（底と逆）に存在しているため、スタック上位から底に向かって探索が行われる。そのため、コールスタックに積まれたすべての復帰アドレスを取得する必要があるといえる。しかし、この終端情報は“除外すべき情報”と“抽出すべき情報”の境界に存在しているので、この終端情報を事前にリストアップして置き、コールスタックの探索時に利用することで、すべての復帰アドレスを取得することなく、中断できる。
【０１１９】
図16は関数モデルの例である。第３の実施形態に係る関数モデルは、ソースコードより、関数呼び出しの関係を抽出して生成したオートマトンである。関数モデルは関数ごとに存在し、節点は、（１）関数入り口（Entry）、（２）関数出口（Exit）、および（３）関数名の３種類のいずれかであり、節点への入り線は関数呼び出しとして、又節点からの出線は関数復帰として定義されるオートマトンである。図16（a）はソースコードの例、図16（b）はソースコードを解析して作られた関数モデルの例である。
【０１２０】
なお、関数モデルは、push、popの検証を行えればよいので、関数モデルの表現はオートマトンでなくてもよい。例えば、オートマトンの各節点に対して、ある節点を開始点として、ある節点を目的点とした場合に、開始点から目的点までの経路が存在するか否かを解析した結果を表で表現してもよい。図17は、図16（a)で示したソースコードから生成した、表形式で表現した関数モデルの例である。“○”は経路が存在することを、“×”は経路が存在しないことを表している。
【０１２１】
モデル取得部5170は、関数モデルDB 50から監視対象プロセス10の動作検証に適した関数モデルを取得して、モデル記憶部5180に記録する。後述するが、動作監視部5140は、pop情報、push情報のフレームごとに検査に適切な関数モデルを要求するので、モデル記憶部5180に必要な関数モデルがない場合に、関数モデルDB50から関数モデルを取得することとなる。又、モデル記憶部5180は、容量が多ければLRUアルゴリズムなどをもちいて管理することで、効率よい動作監視が可能となる。しかし、携帯電話などの組込み機器においては、モデル記憶部となるメモリの容量が限られているため、少ない容量でのモデルの管理が重要となる。又、モデル記憶部5180に記録する際、関数モデルに識別子を付与してもよい。後述するが、モデル記憶部5180に記録された関数モデルは、モデル廃棄部5150によって廃棄される可能性がある。このとき、廃棄対象の関数モデルを特定できるように、関数モデルに識別子を付与するとよい。図18（a）は、識別子が付与された関数モデルの例である。この例では、関数モデルであるオートマトンに、関数名“foo”を付与している。
【０１２２】
動作監視部5140は、スタック差分情報生成部5130が生成したpop情報5135A、push情報5135Bと、モデル記憶に記録されている関数モデル5185とを入力とし、pop情報、push情報と関数モデルとの乖離の有無を判定する。
【０１２３】
図19は、動作監視部5140の動作の例である。検証対象となるpop情報、push情報（図19（a））が入力されると、動作監視部5140は、pop情報、push情報が表す、コールスタックの状況を実現できる制御フローが関数モデル上に存在しているか否かを検証する。例えば、pop情報（図19（a）の(1)）の“q”については、rから復帰しqを終了できることを検証する。図19（b）はqの関数モデルである。ここで、節点rからExitまでのパスが存在しているかを検証する。図19（b）のとおり、qの関数モデルには、r→Exitのパスが存在しているため、qの検証結果は正常であったとする。もし、r→Exitのパスが存在しないようであれば、検証結果は異常であったとする。このように、sからxまで順次検証を行う。Popの動作が正常であった場合、pushの動作を検証する。この検証は、例えば、push情報（図19（a）の(2)）の“f”については、fへ入りgへといたることができるかを検証する。図19（c）は、fの関数モデルである。ここで、節点Entryから次のフレームのgにいたるまでのパスが存在しているかを検証する。図19（c）のとおり、fの関数モデルには、Entry→gのパスが存在しているので、fの検証結果は正常であったとする。もし、Entry→gのパスが存在しないようであれば、検証結果は異常であったとする。このように、push情報のxからhまで順次検証を行う。すべての検証において正常であると判定した場合にのみ、動作監視部140は、結果40として正常と出力する。
【０１２４】
このように、動作監視部5140では、pop情報、push情報の各フレームにおいて、必要な関数モデルを読み込み、パスを検証することになる。図19（d）は、push情報“h”を検証している際のモデル記憶部5180の状況である。ただし、モデル記憶部5180の管理はLRUアルゴリズムに則っていると仮定する。この時点でモデル記憶部5180には、今回の検証で利用した関数モデル以外にも、以前の検証で利用した関数モデルを保持している。
【０１２５】
終端情報取得部5160は、ソフトウェア識別子60と、終端情報35から、監視対象プロセス10に適した終端情報5165を取得し、スタック情報取得部5120に伝える。終端情報の概念は上述したが、一致部分と不一致部分を分ける復帰アドレスであり、監視対象ソフトウェアを事前に実行することにより得た終端情報のリスト（このリストを生成することを「事前学習」という。）は、コールスタックの探索を中断する情報として有用であると述べた。さらに、終端情報よりも底方向に存在するフレームは一致部分であり、動作監視部による検証が及ばないフレームである。このことを利用し、スタック取得部がコールスタックを探索している際に終端情報を検知した場合、それを契機にモデル記憶部5180に存在する、以前の検証で利用した関数モデルを消去してしまうことで、モデル記憶の残り容量を増やすことができる。特に、ソフトウェア動作監視装置5100が利用する終端情報は、事前学習の際に、ユーザから与えられるなどして設定されたしきい値以上の長さをもった期間、コールスタックの底からみて定位置に存在する終端情報である場合を考えると、その効果はさらに顕著になる。main関数を代表とするプログラム（あるいはモジュール）を統括する関数などは、コールスタックの定位置に存在する期間が長く、その位置よりも下位にある復帰アドレスはi番目のスタック情報とi-1番目のスタック情報で一致していることが多い。そのため、長い間定位置に存在する復帰アドレスは本来の終端情報である可能性が高い。このことから、終端情報は、一致部分と不一致部分の境界に存在する復帰アドレスでなくてもよく、コールスタックの定位置に存在する期間が長い復帰アドレスを終端情報として抽出してもよい。
【０１２６】
図20は、事前学習により得られたスタック情報の時系列の例である。スタック情報の中で、mainやX、aは、長い間定位置に存在した復帰アドレスである。このように終端情報として利用されたことがあり、定位置に連続して存在する復帰アドレスを終端情報として抽出する。このようにして得られた終端情報は、一致部分と不一致部分とを分ける位置に必ず存在するとは限らないが、終端情報よりも底方向にあるフレームには多くの一致部分が含まれている。すなわち、終端情報よりも底方向にあるフレームは、検証対象ではない可能性が非常に高い。さらに、この終端情報は一定期間同一のコールスタック位置に存在する復帰アドレスであるので、終端情報よりも底方向にあるフレームはある一定期間検証対象からははずされる。以上を考慮すると、終端情報よりも底方向にあるフレームの関数モデルはモデル記憶から消去しても大きな問題にはならないといえる。
【０１２７】
図21は終端情報を利用してスタック情報取得を中断し、終端到達情報を出力する例を示している。図21（a）は、終端情報取得部5160が取得した終端情報の例である。又、図21（b）は、ある時点でのコールスタックの状況の例である。システムコールが発行され、図21（b）上に示す、コールスタックの状況から、図21（b）下に示す、コールスタックの状況に遷移が起こった場合を考える。なお、コールスタックの状況には復帰アドレスだけでなく関数に渡される引数などが存在するが、説明を簡単にするために、復帰アドレスのみを示している。図21（b）上に示すコールスタックの状況から、スタック上位より復帰アドレスを順次取得していく。取得しながら、終端情報と比較をしていくと、終端情報と一致するxを検知する。この時点で、復帰アドレス取得を中断し、記録していた復帰アドレスを、xを含めてスタック情報として出力し、終端到達情報を出力する（図中のs,r,q,p,x）。図21（b）下に示すコールスタックの状況からも同様に、終端情報と一致するxを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスを、xを含めてスタック情報として出力し、終端到達情報を出力する（図中のh,g,f,x）。こうして得られたスタック情報は、次ステップであるスタック差分情報生成部5130によってスタック差分情報（pop情報、push情報）となる（図21（b）右）。
【０１２８】
モデル廃棄部5160は、終端到達情報5125Bを入力として受けると、モデル記憶部5180に格納されている関数モデルを消去する命令（廃棄命令5155）を出力し、モデル記憶部5180に格納されている関数モデルを消去する。消去対象の関数モデルは、モデル記憶部5180に存在している関数モデルすべてでもよいし、例えば、一時的にLRUアルゴリズムの閾値を変化させるなどして使用される頻度が少ないと判定された関数モデルというように選択してもよい。この消去対象の関数モデルを決定付けるのは、予め設計段階で設定してあってもよいし、ポリシー文書を用いるなどして外部から入力してもよい。なお、現在のメモリ使用量200を取得し、メモリ使用量に応じて、廃棄命令を出力するか否かを切り替えてもよい。又、関数モデルに識別子が付与されている場合、廃棄命令5155に廃棄対象の関数モデルの識別子を含めることで、廃棄対象を特定できる。図18（b）は、廃棄命令5155の例である。廃棄命令に廃棄対象の関数モデル識別子“foo”、“foo2”を伝える例（図18（b）下）、および、すべてが廃棄対象である意味の“all”を伝える例（図18（b）上）を示している。“foo”や“foo2”はハッシュ値を取ってもよい。その際、“all”は、関数モデル識別子と衝突しない値を取ってもよい。
【０１２９】
図22は、モデル廃棄部による関数モデルの廃棄の例である。ここでは消去対象はモデル記憶に存在しているモデルすべてとしている。図22（a）は、スタック情報取得部からの出力の例である。図18（a）の(1)、(2)は、それぞれ、i-1番目のスタック情報、i番目のスタック情報である。これらのスタック情報は、終端情報“x”の検知によって、コールスタックの探索が中断した結果得られた情報であるとする。すなわち、終端到達情報をうけ、終端到達フラグの状態がONになる(図18(a)の(3))。この状態でのモデル廃棄部の処理は、終端到達フラグによって、以前の検証で利用していた関数モデル“y”、“main”（図22（b）左）を、モデル記憶から廃棄する（図22（b）中）。以降、動作監視部によって関数モデルが要求されることで、モデル取得部によってモデル記憶に検証に必要な関数モデル“s”から“h”が格納される（図22（b）右）。
【０１３０】
図23は、モデル廃棄部が利用する廃棄ポリシーの例である。廃棄ポリシーは、ソフトウェア識別子、廃棄対象の列からなる表であって、ソフトウェアごとに廃棄対象を指定するようになっている。すなわち、ソフトウェア識別子“10”で示されるソフトウェアは廃棄対象をモデル記憶に存在している関数モデルすべてとし、ソフトウェア識別子70、30はLRUアルゴリズムの閾値を一時的に変更して、利用頻度の低い関数モデルを対象としている。閾値は、事前に動作させることで得られるソフトウェアの関数呼び出しの頻度分布から決定してもよい。分布では局所性が認められない場合に、廃棄対象をすべてとするとしてもよい。
【０１３１】
（ソフトウェア動作監視方法）
次に、第３の実施形態に係るソフトウェア動作監視方法について、図24及び図25を参照して説明する。
【０１３２】
まず、図24を参照して、スタック情報取得部5120の動作例について説明する。
【０１３３】
まず、スタック情報取得部5120は、終端情報取得部5160から終端情報を得る（ステップS5500）。コールスタックの状況25より、順次スタックフレームを取得し（ステップS5510）、当該スタックフレームの復帰アドレスを取得する（ステップS5520）。
【０１３４】
次に、スタック情報取得部5120は、終端情報を順次読み込み、ステップS5520で取得した復帰アドレスと終端情報とを比較する（ステップS5530）。ステップS5530は、終端情報が終わるまで、もしくは、復帰アドレスと終端情報との一致が確認されるまで続ける。終端情報が終わるまで一致が確認されなかったら、復帰アドレスをスタック情報として記録し（ステップS5540）、スタックフレームが終わるまでステップS5510からステップS5540までを繰り返す。ステップS5530で一致が確認された場合は、ループを抜け、終端情報を検知した旨を表す終端到達情報を出力し（ステップS5550）、スタック情報取得部を終了する。終端到達情報は、コールスタックの探索をしている際に終端情報を検知する旨を伝え、モデル廃棄部5150を起動するトリガとして利用すればよいので、例えば、モデル廃棄部5150の動作起動を管理するフラグがあったとして、そのビットを立てるとしてもよい。
【０１３５】
次に、図25を参照して、モデル廃棄部5160の動作例について説明する。
【０１３６】
まず、モデル廃棄部5160は、終端到達情報を受けた際に消去対象とする関数モデルを理解するための廃棄ポリシーを取得する（ステップS5100）。次に、監視対象プロセスが終了したことの検証と、終端到達情報を受けたことの検証を行い（それぞれ、ステップS5120、S5130）、どちらの事象も検知されなかった場合は、S5110からS5130までを繰り返す。
【０１３７】
ステップS5120で事象を検知した場合は、モデル廃棄処理を終了する。又、ステップS5130で事象を検知した場合は、現在のプロセスメモリ使用量を取得し（ステップS5140）、メモリ使用量がある閾値を超えたか否かを検証する（ステップS5150）。メモリ使用量が閾値を超えなかった場合は、ステップS5110へ戻り、閾値を超えた場合は、モデル記憶内の関数モデルを廃棄ポリシーに則って消去し（ステップS5160）、ステップS5110へ戻る。
【０１３８】
第３の実施形態では、消去対象関数モデルを決定するためにポリシーを利用するとしているが、予め定められている場合は、ポリシーを必要としない。その場合はステップS5100を除外してもよい。又、第３の実施形態では、メモリ使用量に応じて消去するか否かを判定するとしているが、メモリ使用量に応じない場合は、ステップS5140からS5150までを除外してもよい。
【０１３９】
（作用及び効果）
非特許文献１の手法を考慮すると、終端情報以降に現れるスタックフレーム情報で示される関数は、検証対象からはずされる。すなわち、この一致部分に存在する関数の関数モデルはメモリ上に存在していなくてもよい。そこで、第３の実施形態に係るソフトウェア動作監視装置は、コールスタックの探索の際に、終端情報とマッチする復帰アドレスの検知を契機に、コールスタックの探索を中断し、更にキャッシュに記録していた関数モデルを廃棄する。
【０１４０】
従って、第３の実施形態に係るソフトウェア動作監視装置によると、監視対象ソフトウェアの動作をソフトウェア実行中に監視する際、不要な関数モデルをメモリから排除することができるため、監視装置全体の空間オーバーヘッドを、時間オーバーヘッドを抑制した状態で削減することができる。又、メモリ上に残存した不要な関数モデルをメモリから排除することができ。使用メモリ量を抑えることができる．
関数モデルの廃棄は、次のシステムコール発生時のスタック差分情報の検証の際に必要となる関数モデルの廃棄をしてしまう恐れがある。そこで、終端情報取得部は、事前に取得したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することで，検証の際に、ある期間利用されない関数モデルのみを廃棄することができるので、終端情報に基づく関数モデルの廃棄に伴うリスクを軽減することができる。
【０１４１】
又、メモリの空き状況によっては、関数モデルを廃棄せずにLRUアルゴリズムなどでキャッシングしたほうが、時間オーバーヘッドを軽減できる可能性がある。そこで、モデル廃棄部は、現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えることで、必要な場合にのみ関数モデルを廃棄できるため、リスクを軽減することができる。
【０１４２】
又、特に、スタックフレーム情報は、復帰アドレスであることを特徴とすることで、コールスタックを修正することなく、スタックフレームを識別する情報を取得することができる。
【０１４３】
又、関数モデルをある期間記憶するモデル記憶（メモリ、キャッシュなど）に接続し、モデル取得部は、取得した関数モデルに識別子をつけてモデル記憶に記録し、モデル廃棄部は、識別子で廃棄する関数モデルを指定する廃棄命令をモデル記憶部に伝えることを特徴とすることで、廃棄する関数モデルを特定することができる。
【図面の簡単な説明】
【０１４４】
【図１】第１の実施形態に係るソフトウェア動作モデル化装置の構成ブロック図である。
【図２】第１の実施形態に係るスタック情報、スタック差分情報及び終端情報の例である。
【図３】第１の実施形態に係るスタック情報及び終端情報の例である（その１）。
【図４】第１の実施形態に係るスタック情報及び終端情報の例である（その２）。
【図５】第１の実施形態に係るソフトウェア動作モデル化方法を示すフローチャートである。
【図６】図５のS12の詳細を示すフローチャートである。
【図７】第１の実施形態に係る終端情報記録部が利用するリストの例である。
【図８】図５のS13の詳細を示すフローチャートである。
【図９】第１の実施形態に係るソフトウェア動作監視装置の構成ブロック図である。
【図１０】第１の実施形態に係る終端情報を利用してスタック情報取得を中断する例である（その１）。
【図１１】第１の実施形態に係る終端情報を利用してスタック情報取得を中断する例である（その２）。
【図１２】第１の実施形態に係るソフトウェア動作監視方法を示すフローチャートである。
【図１３】図１２のステップS22の詳細を示すフローチャートである。
【図１４】第２の実施形態に係るソフトウェア動作モデル化装置及びソフトウェア動作監視装置の構成ブロック図である。
【図１５】第３の実施形態に係るソフトウェア動作監視装置の構成ブロック図である。
【図１６】第３の実施形態に係る関数モデルの例である（その１）。
【図１７】第３の実施形態に係る関数モデルの例である（その２）。
【図１８】第３の実施形態に係る関数モデルと廃棄命令の例である。
【図１９】第３の実施形態に係る関数モデルを利用した動作監視の例である。
【図２０】第３の実施形態に係るスタック情報及び終端情報の例である。
【図２１】第３の実施形態に係る終端情報を利用してスタック情報取得を中断する例である。
【図２２】第３の実施形態に係る関数モデルの廃棄例である。
【図２３】第３の実施形態に係る廃棄ポリシーの例である。
【図２４】第３の実施形態に係るソフトウェア監視方法を示すフローチャートである（その１）。
【図２５】第３の実施形態に係るソフトウェア監視方法を示すフローチャートである（その２）。
【符号の説明】
【０１４５】
10…監視対象プロセス
15…システムコール
20…メモリ空間
25…コールスタックの状況
30…しきい値
35…終端情報
40…結果
50…モデル情報
55…関数モデル
70…ソフトウェア識別子
100…ソフトウェア動作モデル化装置
110…システムコール情報取得部
115…システムコール情報
120…スタック情報記録部
125…スタック情報
130…スタック差分情報生成部
135…スタック差分情報
140…モデル生成部
150…終端情報記録部
200…メモリ使用量
335…スタック差分情報
500…ソフトウェア動作監視装置
510…システムコール情報取得部
515A、515B…システムコール情報
520…スタック差分情報取得部
530…スタック差分情報生成部
530…動作モデル
535…スタック差分情報
540…動作監視部
550…終端情報取得部
555…終端情報
560…モデル取得部
565…モデル
1000…ソフトウェア動作監視装置
1010…システムコール取得部
1010…システムコール情報取得部
1020…スタック情報記録部
1030…スタック情報取得部
1040…スタック差分情報生成部
1050…モデル生成部
1055…モデル情報
1060…モデル取得部
1070…動作監視部
1080…終端情報記録部
1085…終端情報
1090…終端情報取得部
5100…ソフトウェア動作監視装置
5110…システムコール発行検知部
5115…検知情報
5120…スタック情報取得部
5120…スタック情報記録部
5125A…スタック情報
5125B…終端到達情報
5130…スタック差分情報生成部
5135A…pop情報
5135B…push情報
5140…動作監視部
5150…モデル廃棄部
5155…廃棄命令
5160…モデル廃棄部
5160…終端情報取得部
5165…終端情報
5170…モデル取得部
5175…関数モデル
5180…モデル記憶部
5185…関数モデル
【技術分野】
【０００１】
本発明は、ソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法に関する。
【背景技術】
【０００２】
PCやワークステーション、サーバ、ルータ、携帯電話、PDAなど、すべての計算機は外部もしくは内部からの攻撃にさらされている。代表的な攻撃は、計算機上で実行されているソフトウェアの脆弱性を踏み台にしたものである。攻撃者は、ソフトウェアの脆弱性を利用した悪意のあるコードを計算機に送り込み、実行中のプロセスの制御を奪い、当該プロセスの権限を利用して不正操作をおこなう。
【０００３】
脆弱性を利用した攻撃、特に未知の攻撃を検知するために、ソフトウェアの正常な動作をモデル化し、ソフトウェア実行中にモデルからの乖離の有無を判定する異常検知システムがある。システムコールは、プロセスがカーネルにシステム上重要な処理を依頼する際に行う命令であり、攻撃者は、プロセスが依頼するシステムコールを用いて、システムに任意の行動をさせる。そのため、ソフトウェアの動作を監視する際にシステムコールの正当性を検証することが行われる（例えば、特許文献１、非特許文献１、非特許文献２参照。）。
【０００４】
特許文献１に記載の攻撃対策装置では、システムコール発行元の関数がメモリのコード領域に存在することを正常とし、ソフトウェア（タスク）から発行されたシステムコール要求を入力し、正当性検査機能へのジャンプアドレスを出力するシステムコールテーブルと、システムコール要求発行時にOSによって特定のメモリ領域に格納されるシステムコール呼び出し元の復帰アドレスから、システムコール要求の正当性を判定し判定結果を出力するとともに、不正なシステムコール要求と断定した場合、そのシステムコール要求を棄却する正当性検査機能部と、正当性検査機能部の不正システムコール要求判定結果を入力し、対策を講ずる攻撃対策機能部と、正当性検査機能部の正当システムコール要求判定結果を入力して呼び出され、命令を実行するシステムコールとを備える。
【０００５】
非特許文献１に記載の攻撃検知システムでは、システムコールの正当性を検証するために、コールスタックの状況（スタックに積まれた復帰アドレスの列）を利用する。このシステムでは、まずソフトウェアを事前に実行し、得られた結果からモデルを学習する。プログラム実行中にシステムコール発生時のコールスタックの状況を取得し、システムコール発生時のプログラムカウンタとともに記録したVirtual Stack Listを生成し、又、現在のVirtual Stack Listと一つ前のVirtual Stack Listとの差分情報、すなわち比較対象のコールスタックの状況のスタック最下位より比較検証を順次行い異なる復帰アドレスを検出してから以降の復帰アドレスの列（Virtual Path）を生成する。生成されたVirtual Stack ListとVirtual Pathからそれぞれハッシュテーブルを生成し、そのテーブルをソフトウェアのモデルとして利用する。ソフトウェアの動作を検証する際には、ソフトウェア実行中に、Virtual Stack ListとVirtual Pathを生成し、モデルであるハッシュテーブルとのマッチングを行い、合致していればシステムコール要求に対し許可をし、合致しなければ、異常であると判定する。
【０００６】
非特許文献２に記載の攻撃検知システムでは、システムコールの正当性を検証するために、コールスタックの状況（スタックに積まれた復帰アドレスの列）を利用する。このシステムでは、監視対象ソフトウェアのバイナリコードを解析することによって、関数定義と、関数定義のオートマトンを生成する。このオートマトンは関数ごとに作られ、ソフトウェアの制御フローを監視するために用いられる。節点は、（１）関数の入り口、（２）関数の出口、（３）関数の呼び出しのいずれかとして定義されている。監視対象ソフトウェアの実行中、このシステムは、システムコールが発行されるたびに当該ソフトウェアを停止させ、その時点のコールスタックの状況を調べる。そして、復帰アドレス列から、呼び出されている関数のリスト（スタックバックトレースと呼ぶ）をつくる。そして、iを自然数とすると、i-1番目のスタックバックトレースと、i番目のスタックバックトレースを比較し、前者から後者に至る制御フローがモデル（オートマトン）に存在しているか否かを検証する。
【０００７】
LinuxをはじめとするOSにおいては、通常システムコールがWrapper関数を介して発行される。Wrapper関数はコード領域に存在しているため、システムコール発行元の関数は常にコード領域に存在する。又、攻撃として主流であるReturn-to-libc攻撃の場合、攻撃者はlibcへ復帰させて任意のシステムコールを発行する。以上の状況を考えると、システムコール発行元の関数のアドレスがコード領域にあることで正当とみなしてしまう特許文献１記載の攻撃対策装置では、検知できない攻撃が存在する。又、非特許文献１、非特許文献２記載の攻撃検知システムは、コールスタックに積まれた復帰アドレスの列を用いて検証をしているため、特許文献１記載の攻撃対策装置よりも詳細なモデル化を行っているといえる。そのため、攻撃見逃しを特許文献１よりも低減している。
【特許文献１】特開２００４−１２６８５４号公報
【非特許文献１】H.Fengら, “Anomaly Detection Using Call Stack Information”, The proc. of IEEE Symposium on Security and Privacy 2003, pp.62.
【非特許文献２】阿部ら，“静的解析に基づく侵入検知システムの最適化”，情報処理学会論文誌：コンピューティングシステム，vol.45，No.SIG3 (ACS 5)，pp.11-20
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１、非特許文献１ともに、ソフトウェアの動作をプログラム実行中に検証することを前提としているが、携帯電話など処理能力の低い計算機において、動作を検証するシステムを搭載するためには、限られた資源での処理の高速化、使用メモリ量の抑制が重要となる。
【０００９】
特に、非特許文献１では、精度を向上させるために、コールスタックの状況をモデルに含めており、検証の際にシステムコール発行のタイミングでコールスタックの状況を都度取得する必要がある。コールスタックの状況を取得するためには、スタックポインタ（SP）、ベースポインタ（BP）を利用してコールスタック内を探索し、スタックフレームを識別するスタックフレーム情報（位置、復帰アドレス、カナリなど）を順次取得する必要があるが、コールスタックはメモリ上に展開されているので、低速なメモリアクセスが頻繁に起き、時間オーバーヘッドが高い。
【００１０】
又、特に、非特許文献２では、精度向上のために、コールスタックの状況を監視しているが、スタックバックトレースにリストアップされた関数ごとにモデルを読み込み、制御フローの検証を行う必要がある。監視の速度を高速にするためには、読み込んだモデルをLRUアルゴリズムによってキャッシングすることが考えられるが、組み込み機器ではメモリ量が限られてしまうため、結果的には使用されないかもしれないモデルをメモリにおいておくことは、使用メモリ量を圧迫させてしまい、監視対象ソフトウェアの処理を著しく悪化させてしまう可能性がある。
【００１１】
そこで、本発明は、上記の問題に鑑み、攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減するソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するため、本発明の第１の特徴は、（ａ）ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するスタック情報記録部と、（ｂ）iを自然数とし、スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とを、コールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録する終端情報記録部と、（ｃ）終端情報記録部が記録した終端情報を用いて、スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成する第１のスタック差分情報生成部と、（ｄ）スタック差分情報から、当該ソフトウェアの動作モデルを生成するモデル生成部とを備えるソフトウェア動作モデル化装置であることを要旨とする。
【００１３】
第１の特徴に係るソフトウェア動作モデル化装置によると、監視の際にコールスタックの探索を中断する箇所を本来の終端情報の位置（場合によってはその近傍）に設定するための終端情報をソフトウェア毎に記録することができる。又、監視の際に，終端情報を用いてコールスタックの探索を中断する場合でも利用可能なモデルを生成することができる。このため、第１の特徴に係るソフトウェア動作モデル化装置によると、攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減することができる。
【００１４】
又、第１の特徴に係るソフトウェア動作モデル化装置において、終端情報記録部は、特定のイベントの識別子と終端情報の共起頻度の高い終端情報を、特定のイベントの識別子とともに記録し、スタック差分情報生成部は、終端情報記録部が記録した終端情報から、特定のイベントの識別子を利用して、スタック差分情報の生成に用いる終端情報を取得してもよい。
【００１５】
このソフトウェア動作モデル化装置によると、特定のイベント（システムコールなど）との共起関係の強い終端情報を記録することで、監視の際に、特定のイベントごとに特化した終端情報を利用することができる。
【００１６】
又、第１の特徴に係るソフトウェア動作モデル化装置において、終端情報記録部は、スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録してもよい。
【００１７】
このソフトウェア動作モデル化装置によると、記録する終端情報と本来の終端情報との差（コールスタック内での位置の違い）を小さく保ったまま、記録する終端情報の数を少なくすることができる。
【００１８】
更に、終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間の長さを把握し、期間が長いスタックフレーム情報を終端情報として記録してもよい。
【００１９】
又、第１の特徴に係るソフトウェア動作モデル化装置において、モデル生成部によって生成された、監視対象となるソフトウェアの動作モデルを取得するモデル取得部と、終端情報記録部によって記録された終端情報を取得する終端情報取得部と、コールスタックを検索している際に、終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成する第２のスタック差分情報生成部と、スタック差分情報生成部が生成したスタック差分情報と、モデル取得部が取得した動作モデルとの乖離を判定する動作監視部とを更に備えてもよい。
【００２０】
このソフトウェア動作モデル化装置によると、同一の端末上でのモデル化、監視の実現に加え、終端情報を利用した効率のよい、コールスタックの探索を実現できる。
【００２１】
又、第１の特徴に係るソフトウェア動作モデル化装置において、スタックフレーム情報は、復帰アドレスであってもよい。
【００２２】
このソフトウェア動作モデル化装置によると、コールスタックを修正することなく、スタックフレームを識別する情報を取得することができる。
【００２３】
本発明の第２の特徴は、（ａ）監視対象ソフトウェアが発行した特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを関数モデルとしたとき、監視対象のソフトウェアが発行した特定のイベントごとに、前記関数モデルを取得するモデル取得部と、（ｂ）ソフトウェアの実行環境において、監視対象のソフトウェアに適した終端情報を取得する終端情報取得部と、（ｃ）当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、（ｄ）スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するスタック差分情報生成部と、（ｅ）スタック差分情報生成部が生成したスタック差分情報と、モデル取得部が取得した動作モデルとの乖離を判定する動作監視部とを備えるソフトウェア動作監視装置であることを要旨とする。
【００２４】
第２の特徴に係るソフトウェア動作監視装置によると、学習時に得られた終端情報を利用して、コールスタックの探索を中断でき、監視にかかるオーバーヘッドを軽減することができる。特に、終端情報取得部は、事前に取得した特定のイベントの識別子と終端情報の共起頻度の高い終端情報を特定のイベントの識別子とともに記録した情報を、特定のイベントの識別子に基づいて取得することで，コールスタック探索の中断の確認において、特定のイベントとの共起関係の強い終端情報をつかうことができるので、特定のイベントに適した中断を行うことができる。
【００２５】
又、第２の特徴に係るソフトウェア動作監視装置は、モデル取得部によって記録された関数モデルを廃棄するモデル廃棄部を更に備え、モデル取得部は、事前に監視対象ソフトウェアのコードから関数ごとに生成した、関数相互の呼び出しの関係を示す関数モデルを取得し、動作監視部は、スタック差分情報生成部によって生成されたスタック差分情報と、モデル取得部が取得した関数モデルとの乖離を判定し、スタック情報取得部は，コールスタックからスタックフレーム情報を取得する際に、終端情報と一致するスタックフレーム情報を検知した場合に、スタックフレーム情報の取得を中断し、その場合、モデル廃棄部は、モデル取得部が以前のスタック差分情報の監視のために記録した関数モデルを廃棄してもよい。
【００２６】
このソフトウェア動作監視装置によると、メモリ上に残存した不要な関数モデルをメモリから排除することができ、使用メモリ量を抑えることができる。
【００２７】
関数モデルの廃棄は、次のシステムコール発生時のスタック差分情報の検証の際に必要となる関数モデルの廃棄をしてしまう恐れがある。そこで、終端情報取得部は、事前に取得したスタック情報の時系列から、ある期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することで、検証の際に、ある期間利用されない関数モデルのみを廃棄することができるので、終端情報に基づく関数モデルの廃棄に伴うリスクを軽減することができる。
【００２８】
又、第２の特徴に係るソフトウェア動作監視装置において、終端情報取得部は、スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得してもよい。
【００２９】
このソフトウェア動作監視装置によると、終端情報の確認結果をキャッシュに保存するなどして効率化を図ることができる。
【００３０】
更に、終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間が長いスタックフレーム情報を終端情報として記録した情報を取得してもよい。
【００３１】
又、第２の特徴に係るソフトウェア動作監視装置において、モデル廃棄部は、システムの現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えてもよい。
【００３２】
メモリの空き状況によっては、関数モデルを廃棄せずにLRUアルゴリズムなどでキャッシングしたほうが、時間オーバーヘッドを軽減できる可能性がある。このソフトウェア動作監視装置によると、モデル廃棄部は、現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えることで、必要な場合にのみ関数モデルを廃棄できるため、リスクを軽減することができる。
【００３３】
又、第２の特徴に係るソフトウェア動作監視装置は、関数モデルを記憶するモデル記憶部を更に備え、モデル取得部は、取得した関数モデルに識別子をつけてモデル記憶に記録し、モデル廃棄部は、識別子で廃棄する関数モデルを指定する廃棄命令をモデル記憶部に伝えてもよい。
【００３４】
このソフトウェア動作監視装置によると、廃棄する関数モデルを特定することができる。
【００３５】
本発明の第３の特徴は、（ａ）ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するステップと、（ｂ）iを自然数とし、スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とをコールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録するステップと、（ｃ）終端情報記録部が記録した終端情報を用いて、スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成するステップと、（ｄ）スタック差分情報から、当該ソフトウェアの動作モデルを生成するステップとを含むソフトウェア動作モデル化方法であることを要旨とする。
【００３６】
又、本発明の第４の特徴は、（ａ）監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを取得するステップと、（ｂ）ソフトウェアの実行環境において、監視対象のソフトウェアに適した終端情報を取得するステップと、（ｃ）当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報をコールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するステップと、（ｄ）スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するステップと、（ｅ）スタック差分情報生成部が生成したスタック差分情報と、モデル取得部が取得した動作モデルとの乖離を判定するステップとを含むソフトウェア動作監視方法であることを要旨とする。
【発明の効果】
【００３７】
本発明によると、攻撃を正確に検知し、ソフトウェア動作監視における時間及び空間オーバーヘッドを削減するソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法を提供することができる。
【発明を実施するための最良の形態】
【００３８】
次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。ただし、図面は模式的なものであることに留意すべきである。
【００３９】
＜第１の実施の形態＞
（ソフトウェア動作モデル化装置）
第1の実施形態に係るソフトウェア動作モデル化装置100は、図１に示すように、監視対象プロセス10、監視対象プロセスが利用するメモリ空間20、任意でしきい値30を用いて、監視対象プロセス10の正常な動作を表すモデル情報50と、終端情報40を生成し、出力する。ここで、「監視対象プロセス10」とは、ソフトウェアの動作を監視すべきソフトウェアの実行形態をいう。当該監視対象プロセス10の監視指示は、ユーザによって外部から与えられてもよく、ソフトウェア配信者がソフトウェアに付与したメタ情報によって与えられてもよい。
【００４０】
ソフトウェア動作モデル化装置100は、システムコール情報取得部110と、スタック情報記録部120と、スタック差分情報生成部130と、モデル生成部140と、終端情報記録部150とを備える。
【００４１】
システムコール情報取得部110は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報記録部120がスタック情報を記録するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール番号などを含むシステムコール情報115を取得する。システムコール情報取得部110は、デバッグツールで実現できるが、例えば，Linuxに実装されているptraceを利用することで、容易に実現できる。
【００４２】
なお、第1の実施形態に係るソフトウェア動作モデル化装置100では、特定のイベントとして監視対象プロセス10が発行するシステムコールとしているが、本発明はそれのみにこだわる必要はない。システムコール以外の特定のイベントとは、たとえば、jmp命令などがあげられる。たとえば、Linuxに実装されているptraceを利用し、1ステップ実行を行うことで、インストラクションを取得することが可能なので、ソフトウェア動作モデル化装置がjmp命令を検知できる。
【００４３】
スタック情報記録部120は、システムコール情報取得部110がシステムコールを検知した時点でのコールスタックの状況25を、監視対象プロセスが利用するメモリ空間20から取得する。ここで、「コールスタックの状況」とは、スタックフレームの積まれた状態をいう。コールスタックの状況から、スタックフレームを識別する情報を取得する。ここで、「スタックフレームを識別する情報」とは、例えば、復帰アドレスやカナリなどがあげられる。カナリは、バッファーオーバーフロー脆弱性をついたスタックスマッシング攻撃を防止するために用いられる、スタックフレームごとに挿入される値のことである。カナリが、スタックフレームが生成された時点と比較して異なる値を示した場合、スタックフレームがスタックスマッシング攻撃によって破壊されたとして検知することができる。このカナリは、攻撃者が推定できると意味を成さないので、乱数を利用することが多いが、このカナリに、スタックフレームを識別できる情報を含めることも可能である。そのようにカナリを設計することで、カナリを取得すれば、スタックフレームを識別することができる。
【００４４】
第１の実施形態では、復帰アドレスを用いてスタックフレームを識別するとして詳しく説明する。すなわち、コールスタックの状況から復帰アドレスのみを抽出して、スタック情報として出力する。抽出の仕方はいろいろあるが、x86やARMなどのコールスタックでは、復帰アドレスはスタックフレームの最上位（底部の逆）に存在しているので、例えば、レジスタに保持されたスタックポインタとベースポインタを利用して、ベースポインタの直下の値を取得することで実現できる。スタック情報は、スタック情報記録部120によってシステムコールが発行されたタイミングで、時系列順に記録される。
【００４５】
終端情報記録部150は、スタック情報記録部120によって記録されたi-1番目のスタック情報と、i番目のスタック情報とを底から順に比較し、コールスタックの位置と復帰アドレスが一致している部分を一致部分、異なる復帰アドレスを検知してから以降の部分を不一致部分とし、一致部分と不一致部分の境界を作る。この不一致部分の端に位置する復帰アドレスを「終端情報」という。
【００４６】
図2は、スタック情報、一致部分、不一致部分、スタック差分情報、終端情報の例を示している。図2(a)に示すように、i-1番目のスタック情報と、i番目のスタック情報とを比較すると、一致部分が図2（b）に示すように、不一致部分が図3（c）に示すようになる。一致部分と不一致部分を分かつ復帰アドレスは“x”であるので、図3（e）に示すように、終端情報はxとなる。又、モデル化に利用するスタック差分情報とは、図3（d）に示すように、不一致部分を連結した情報である。スタック差分情報を生成する際には、スタック情報から一致部分を除外し、不一致部分を抽出する処理を行う。この場合、スタック情報は底から検証する必要があるが、コールスタックの探索においては、スタックポインタがスタック上位（底と逆）に存在しているため、スタック上位から底に向かって探索が行われる。そのため、コールスタックに積まれたすべての復帰アドレスを取得する必要があるといえる。しかし、この終端情報は“除外すべき情報”と“抽出すべき情報”の境界に存在しているので、この終端情報を事前にリストアップしておき、コールスタックの探索時に利用することで、すべての復帰アドレスを取得することなく中断できる。
【００４７】
終端情報記録部150は、スタック情報記録部120が記録したスタック情報125Aから、任意でしきい値30を利用して、終端情報40を記録する。終端情報は、記録したスタック情報の中に多く存在するので、そのすべてをリストアップしてもよいが、コールスタックの探索時に有用な情報を抽出してもよい。例えば、スタック情報はシステムコール時に生成されたので、システムコール識別子と終端情報の共起関係を把握し、共起頻度の高い終端情報を記録することがあげられる。図3（a）は、スタック情報記録部120が記録したスタック情報の例である。システムコール識別子と終端情報の共起頻度を調査し、システムコールごとに共起頻度の高い終端情報を抽出する。図3（b）は、そうして抽出された終端情報の例である。
【００４８】
第１の実施形態では、任意のしきい値以上の長さをもった期間、コールスタックの底からみて定位置に存在する終端情報を抽出する例を詳細に説明する。main関数を代表とするプログラム（あるいはモジュール）を統括する関数などは、コールスタックの定位置に存在する期間が長く、その位置よりも下位にある復帰アドレスはi番目のスタック情報とi-1番目のスタック情報で一致していることが多い。そのため、長い間定位置に存在する復帰アドレスは本来の終端情報である可能性が高い。このことから、終端情報は、一致部分と不一致部分の境界に存在する復帰アドレスでなくてもよく、コールスタックの定位置に存在する期間が長い復帰アドレスを終端情報として抽出してもよい。
【００４９】
図4（a）は、スタック情報記録部120が記録したスタック情報の例である。スタック情報の中で、mainやX、aは、長い間定位置に存在した復帰アドレスである。このように定位置に連続して存在する復帰アドレスを抽出する。ここで、しきい値をあたえ、しきい値以上の長さをもつ復帰アドレスを終端情報として抽出してもよい。図4（b）では、しきい値が3である場合で、mainとXが終端情報として抽出される。
【００５０】
ソフトウェア動作モデル化装置100は、終端情報記録部150により得た終端情報40を出力し、更に、終端情報155を用いてスタック差分情報を生成する。
【００５１】
スタック差分情報生成部130は、スタック情報と、終端情報40と、システムコール情報115とを入力として、スタック差分情報135を生成する。スタック差分情報生成部130では、i-1番目のスタック情報とi番目のスタック情報から不一致部分を抽出し、得られた不一致部分を連結させて、スタック差分情報を生成する。
【００５２】
モデル生成部140は、スタック差分情報135から監視対象プロセス10の動作モデルを生成する。例えば、非特許文献１のようにスタック差分情報135のハッシュ値をとる、システムコール識別子とスタック差分情報との相関規則を導出する等である。
【００５３】
（ソフトウェア動作モデル化方法）
次に、第１の実施形態に係るソフトウェア動作モデル化方法について、図５を参照して説明する。
【００５４】
まず、システムコール情報取得部110は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報記録部120がスタック情報を記録するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール番号などを含むシステムコール情報115を取得する（ステップS10）。
【００５５】
次に、スタック情報記録部120は、システムコール情報取得部110がシステムコールを検知した時点でのコールスタックの状況25を、監視対象プロセスが利用するメモリ空間20から取得する（ステップS11）。
【００５６】
次に、終端情報記録部150は、スタック情報記録部120が記録したスタック情報125Aから、任意でしきい値30を利用して、終端情報40を記録する（ステップS12）。尚、終端情報記録部150の動作例については、後に詳述する。
【００５７】
次に、スタック差分情報生成部130は、スタック情報125と、終端情報40と、システムコール情報115とを入力として、スタック差分情報135を生成する（ステップS13）。尚、スタック差分情報生成部130の動作例については、後に詳述する。
【００５８】
次に、モデル生成部140は、スタック差分情報135から監視対象プロセス10の動作モデルを生成する（ステップS14）。
【００５９】
次に、ステップS12の動作例について、図6を参照して詳細に説明する。
【００６０】
まず、終端情報記録部150は、各終端情報の定位置に存在する期間の長さ（以下において、「連続数」という。）をカウントするためのListAと、連続数をもった終端情報を保存するListBを利用する。図7(a)、(b)は、それぞれListA、ListBの例である。ListAは、終端情報とコールスタック底から数えた位置、連続数、スタック情報を検査した後に当該終端情報がカウントアップされたか否かを判定するためのflagから構成される。ListBは、終端情報と、連続数で構成される。
【００６１】
図6のとおり、終端情報記録部150は、まずListAとListBを初期化、すなわちアイテムがまったくない状態にする（ステップS100）。次に、スタック情報を読み込む（ステップS110）。次に、読み込んだスタック情報から、コールスタック底から順次復帰アドレスを読み込む（ステップS120）。この読み込みでは、前回取得したスタック情報との比較を次に行うので、前回取得したスタック情報で、今読み込んだ復帰アドレスの位置と同じ位置に存在する復帰アドレスを読み込む。
【００６２】
次に、読み込んだ復帰アドレスどうしを比較し、不一致であるか否かを検証する（ステップS130）。不一致であった場合、前回のループで読み込んだ復帰アドレスを終端情報とし、ListAを更新する（ステップS140）。ListAの更新では、終端情報がListAに存在しているか否かを検証し、存在していなかったらListAに当該終端情報、位置、連続数=0、flag=0を追加する。
【００６３】
ステップS130において、一致であった場合、もしくは、ステップS140の後に、復帰アドレスあるいは終端情報かつ同じ位置である終端情報がListAに存在しているか否かを検証する（ステップS150）。存在していれば、当該終端情報の連続数を＋１し（ステップS160）、flagを1にする（ステップS170）。
【００６４】
このステップS120からS170までをスタック情報が終了するまで続ける。次に、ListAのアイテムを順次読み込む（ステップS180）。読み込んだアイテムのflagが1であるか否かを検証する（ステップS190）。1でない場合、連続がとまったことになるので、当該終端情報の連続数が確定したことになる。確定した連続数と終端情報を元に、ListBを更新する（ステップS220）。又、当該終端情報の連続数をクリアする（ステップS230）。ステップS190において1であった場合、もしくは、ステップS230の後に、flagを0にする（ステップS200）。
【００６５】
このステップS180からS200までをListAが終わるまで続ける。さらに、ステップS110からステップS200までをスタック情報読み込み終了まで続ける。
【００６６】
こうして得られたListBを、連続数を元に並べ替える（ステップS210）。次に、ListBのアイテムを順次読み込む（ステップS240）。しきい値と連続数を比較し（ステップS250）、しきい値よりも連続数のほうが大きい場合、終端情報を記録する（ステップS260）。このステップS240からS260までをListBが終了するまで続ける。
【００６７】
なお、こうして得た終端情報と、一致部分、不一致部分をわける終端情報との位置の差を誤差情報として、例えば、終端情報とともに外部記録に記録してもよい。
【００６８】
次に、ステップS13での不一致部分抽出ステップの動作例について、図8を参照して詳細に説明する。
【００６９】
まず、スタック差分情報生成部130は、終端情報を取得する（ステップS300）。次に、スタック情報より復帰アドレスを取得する（ステップS310）。次に、終端情報と復帰アドレスが一致しているか否かを検証し（ステップS320）、一致していた場合は、不一致部分抽出ステップを終了する。不一致の場合は、ステップS320を終端情報が終了するまで続ける。終端情報が終わった場合は、ステップS310で取得した復帰アドレスは不一致部分のアイテムであると判断し、記録する（ステップS330）。ステップS310〜S330をスタック情報が終了するまで続ける。
【００７０】
スタック差分情報生成部130は、こうして得られたi番目の不一致部分と前回得たi-1番目の不一致部分とを結合する。結合のさせ方について例で示す。図3（d）に示すスタック差分情報は、図3（c）の不一致部分を結合する際に、システムコールi番目のスタック情報から得た不一致部分の順序を逆にして結合している。これは非特許文献１に習ってそうしているが、順序を逆にしなくてもよい。というのも、モデルをスタック差分情報上の復帰アドレスとシステムコール識別子との相関規則で生成する場合、順序は意味をなさないからである。スタック差分情報は、システムコール識別子とともに出力され、モデル生成部140に伝えられる。
【００７１】
なお、誤差情報を終端情報記録部150で記録している場合、図7のステップS320において、一致であった場合に、すぐに終了せずに、誤差情報分の復帰アドレスを追加で取得し検査してもよい。このようにすることで、本来の終端情報からの乖離の距離が短くなるため、精度のよいモデルを生成することができる。
【００７２】
（ソフトウェア動作監視装置）
次に、第１の実施形態に係る、監視対象プロセス10の動作の正常異常判定を行うソフトウェア動作監視装置について、図9を用いて説明する。
【００７３】
第１の実施形態に係るソフトウェア動作監視装置500は、図9に示すように、監視対象プロセスが利用するメモリ空間20、終端情報40、モデル情報50、ソフトウェア識別子70を利用して、判定結果60を出力する。
【００７４】
ソフトウェア動作監視装置500は、システムコール情報取得部510と、スタック情報取得部520と、終端情報取得部550と、スタック差分情報生成部530と、動作監視部540と、モデル取得部560とを備える。
【００７５】
ソフトウェア動作監視装置500は、ソフトウェアがロードされると、ソフトウェア識別子70とモデル情報50から、監視対象プロセス10の監視に適したモデル565を取得するモデル取得部560を起動させる。
【００７６】
システムコール情報取得部510は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報取得部520がスタック情報の取得を終了するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール情報を取得する。システムコール情報取得部510はLinuxに実装されているptraceを利用することで、容易に実現できる。
【００７７】
終端情報取得部550は、ソフトウェア識別子70と、終端情報40から、監視対象プロセスに適した終端情報555を取得し、スタック情報取得手部520に伝える。終端情報がシステムコール識別子ごとに記録されている場合、終端情報取得部550にさらにシステムコール情報515Aを入力して、監視対象プロセス10によって発行されたシステムコールごとに終端情報を選択する。
【００７８】
スタック情報取得部520は、監視対象プロセスが利用するメモリ空間20からコールスタックの状況25を取得し、更に、終端情報555を利用し、スタック情報525を生成する。スタック情報取得部520は、コールスタックの状況から、スタックフレームを識別する情報を取得する。
【００７９】
第１の実施形態では、復帰アドレスを用いてスタックフレームを識別するとして詳しく説明する。すなわち、スタック情報取得部520は、コールスタックの状況25から、復帰アドレスを取得する。更に、スタック情報取得部520は、終端情報555を利用して、スタックフレームを識別する情報（第１の実施形態では復帰アドレス）の取得を中断する。
【００８０】
図10は、終端情報を利用してスタック情報取得を中断する例を示している。図10（a）は、終端情報取得部550が取得した終端情報の例である。又、図10（b）は、ある時点でのコールスタックの状況の例である。システムコールが発行され、図10（b）上に示すコールスタックの状況から、図10(b)下に示すコールスタックの状況に遷移が起こった場合を考える。なお、コールスタックの状況には復帰アドレスだけでなく関数に渡される引数などが存在するが、説明を簡単にするために、復帰アドレスのみを示している。図10（b）上に示すコールスタックの状況から、スタック上位より復帰アドレスを順次取得していく。取得しながら、終端情報と比較をしていくと、終端情報と一致するxを検知する。この時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のs,r,p,q）。図10（b）下に示すコールスタックの状況からも同様に、終端情報と一致するxを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のh,g,f）。こうして得られたスタック情報は、次ステップであるスタック差分情報生成部530によって結合されスタック差分情報となる（図10(b)右）。
【００８１】
又、図11は、終端情報を利用してスタック情報取得を中断する別の例を示している。図11（a）は、終端情報取得部550が取得した終端情報の例である。図10と異なり、システムコール識別子と対になっている。スタック情報取得部520は、システムコール情報取得部510が取得したシステムコール番号を用いて、システムコールにあわせて終端情報を切り替える。図11（b）は、ある時点でのコールスタックの状況の例である。システムコールが発行され、図11（b）上に示すコールスタックの状況から、図11（b）下に示すコールスタックの状況に遷移が起こった場合を考える。なお、コールスタックの状況には復帰アドレスだけでなく関数に渡される引数などが存在するが、説明を簡単にするために、復帰アドレスのみを示している。図11（b）上のコールスタック状況は、システムコール番号4が発行されて得られた情報であることから、終端情報は、xとなる。コールスタックの上位から順次復帰アドレスを取得し、終端情報と比較し、終端情報xと一致する復帰アドレスを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のs,r,p,q）。同様に、図11（b）下のコールスタック状況の場合、システムコール番号6が発行されて得られた情報であることから、mainが終端情報となる。コールスタックの上位から順次復帰アドレスを取得し、終端情報と比較し、終端情報mainと一致する復帰アドレスを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスをスタック情報として出力する（図中のh,g,f,x,y）。こうして得られたスタック情報は、次ステップであるスタック差分情報生成部530によって結合され、スタック差分情報となる（図10（b）右）。
【００８２】
スタック差分情報生成部530は、スタック情報525と、システムコール情報515Bを入力として、スタック差分情報335を生成する。スタック差分情報生成部530では、i-1番目のスタック情報とi番目のスタック情報から不一致部分を抽出し、得られた不一致部分を連結させて、スタック差分情報を生成する。
【００８３】
モデル取得部560は、監視対象プロセス10が発行した特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを関数モデルとしたとき、監視対象プロセス10が発行したシステムコールごとに、関数モデルを取得する。
【００８４】
動作監視部540は、スタック差分情報生成部520が生成したスタック差分情報535と、モデル取得部560が取得した動作モデル530との乖離を判定し、判定結果60として出力する。
【００８５】
（ソフトウェア動作監視方法）
次に、第１の実施形態に係るソフトウェア動作監視方法について、図12を参照して説明する。
【００８６】
まず、システムコール情報取得部510は、監視対象プロセス10が発行するシステムコール15を検知し、その時点からスタック情報取得部520がスタック情報の取得を終了するまで、監視対象プロセス10を待ち状態にさせる。更に、システムコール15からシステムコール情報を取得する（ステップS20）。
【００８７】
次に、終端情報取得部550は、ソフトウェア識別子70と、終端情報40から、監視対象プロセスに適した終端情報555を取得し、スタック情報取得手部520に伝える（ステップS21）。
【００８８】
次に、スタック情報取得部520は、監視対象プロセスが利用するメモリ空間20からコールスタックの状況25を取得し、更に、終端情報555を利用し、スタック情報525を取得する（ステップS22）。尚、スタック差分情報取得部520の動作例については、後に詳述する。
【００８９】
次に、スタック差分情報生成部530は、スタック情報525と、システムコール情報515Bを入力として、スタック差分情報335を生成する（ステップS23）。
【００９０】
一方、ソフトウェアがロードされると、モデル取得部560は、ソフトウェア識別子70とモデル情報50から、監視対象プロセス10の監視に適したモデル565を取得する（ステップS24）。
【００９１】
次に、動作監視部540は、スタック差分情報生成部520が生成したスタック差分情報535と、モデル取得部560が取得した動作モデル530との乖離を判定し、判定結果60として出力する（ステップS25）。
【００９２】
次に、ステップS22の動作例について、図13を参照して詳細に説明する。
【００９３】
まず、スタック情報取得部520は、終端情報取得部550から終端情報を得る（ステップS500）。次に、コールスタックの状況25より、順次スタックフレームを取得し（ステップS510）、当該スタックフレームの復帰アドレスを取得する（ステップS520）。
【００９４】
次に、スタック情報取得部520は、終端情報を順次読み込み、ステップS520で取得した復帰アドレスと終端情報とを比較する（ステップS530）。ステップS530は、終端情報が終わるまで、もしくは、復帰アドレスと終端情報との一致が確認されるまで続ける。終端情報が終わるまで一致が確認されなかった場合は、復帰アドレスをスタック情報として記録し（ステップS540）、スタックフレームが終わるまで、ステップS510からステップS540までを繰り返す。
【００９５】
ステップS530で一致が確認された場合は、ループを抜け、スタック情報取得処理を終了する。なお、終端情報に誤差情報が付与されている場合は、ステップS530で一致を確認した後に、誤差情報が示す分まで復帰アドレスを取得するステップを追加してもよい。
【００９６】
（作用及び効果）
第１の実施形態に係るソフトウェア動作モデル化装置は、記録した終端情報を抽出し、終端情報に基づいて、スタック情報からソフトウェアの動作モデルを生成する。
【００９７】
このため、第１の実施形態に係るソフトウェア動作モデル化装置によると、監視の際にコールスタックの探索を中断する箇所を本来の終端情報の位置（場合によってはその近傍）に設定するための終端情報をソフトウェア毎に記録することができる。又、監視の際に、終端情報を用いてコールスタックの探索を中断する場合でも利用可能なモデルを生成することができる。
【００９８】
特に、特定のイベント（システムコールなど）との共起関係の強い終端情報を記録することで、監視の際に、特定のイベントごとに特化した終端情報を利用することができる。
【００９９】
又特に、スタック情報記録部が記録したスタック情報の時系列から、ある期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録することで，記録する終端情報と本来の終端情報との差（コールスタック内での位置の違い）を小さく保ったまま、記録する終端情報の数を少なくすることができる。
【０１００】
又、特に、スタックフレーム情報は、復帰アドレスであることを特徴とすることで、コールスタックを修正することなく、スタックフレームを識別する情報を取得することができる。
【０１０１】
又、第１の実施形態に係るソフトウェア監視装置は、コールスタック検索の際に、終端情報とマッチする復帰アドレスの検知を契機に、コールスタックの探索を中断し、その時点までで得られたスタック情報で動作検証を行う。
【０１０２】
このため、第１の実施形態に係るソフトウェア監視装置によると、監視対象ソフトウェアの動作をソフトウェア実行中に監視する際、学習時に得られた終端情報を利用して、コールスタックの探索を中断でき，監視にかかるオーバーヘッドを軽減することができる。
【０１０３】
特に、終端情報取得部は、事前に取得した特定のイベントの識別子と終端情報の共起頻度の高い終端情報を特定のイベントの識別子とともに記録した情報を、特定のイベントの識別子に基づいて取得することで、コールスタック探索の中断の確認において，特定のイベントとの共起関係の強い終端情報をつかうことができるので、特定のイベントに適した中断を行うことができる。
【０１０４】
又、特に、終端情報取得部は、事前に取得したスタック情報の時系列から、ある期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することで，終端情報の確認結果をキャッシュに保存するなどして効率化を図ることができる。
【０１０５】
＜第２の実施形態＞
（ソフトウェア動作モデル化及びソフトウェア動作監視装置）
図14は、第２の実施形態に係るソフトウェア動作モデル化及びソフトウェア動作監視装置1000の構成例を示すブロック図である。
【０１０６】
ソフトウェア動作モデル化及びソフトウェア動作監視装置1000は、監視対象プロセス10の動作を表すモデル情報1055をモデル情報DB50に格納し、さらに、終端情報1085を終端情報DB30に格納する装置である。さらに、ソフトウェア動作監視装置1000は、監視対象プロセス10の動作の監視に適したモデル情報55、終端情報35を、モデル情報DB50、終端情報DB30からそれぞれ取得し、監視対象プロセス10の動作の検証を行い、検証結果60を出力する装置である。
【０１０７】
ソフトウェア動作モデル化及びソフトウェア動作監視装置1000は、システムコール情報取得部1010と、スタック情報記録部1020と、スタック情報取得部1030と、スタック差分情報生成部1040と、モデル生成部1050と、モデル取得部1060と、動作監視部1070と、終端情報記録部1080と、終端情報取得部1090とを備える。
【０１０８】
監視対象プロセス10の動作をモデル化する場合、ソフトウェア動作監視装置1000は、システムコール情報取得部1010、スタック情報記録部1020、スタック差分情報生成部1040、モデル生成部1050、終端情報記録部1080を起動する。それぞれの構成要素は、第１の実施形態に記載のソフトウェア動作モデル化装置100における、システムコール情報取得部110、スタック情報記録部120、スタック差分情報生成部130、モデル生成部140、終端情報記録部150と同様としてもよい。詳細は、第１の実施形態を参照されたい。
【０１０９】
監視対象プロセス10の動作を監視する場合、ソフトウェア動作監視装置1000は、システムコール取得部1010、スタック情報取得部1030、スタック差分情報生成部1040、モデル取得部1060、動作監視部1070、終端情報取得部1090を起動する。それぞれの構成要素は、第１の実施形態に記載のソフトウェア動作監視装置500における、システムコール情報取得部510、スタック情報取得部520、スタック差分情報生成部530、モデル取得部560、動作監視部540、終端情報取得部550と同様としてもよい。詳細は、第１の実施形態を参照されたい。
【０１１０】
（作用及び効果）
第２の実施形態に係るソフトウェア動作モデル化及びソフトウェア動作監視装置によると、同一の端末上でのモデル化、監視の実現に加え、終端情報を利用した効率のよいコールスタックの探索を実現できる。
【０１１１】
＜第３の実施形態＞
図15は、第3の実施形態に係るソフトウェア動作監視装置5100の構成例を示すブロック図である。
【０１１２】
ソフトウェア動作監視装置5100は、関数モデルをある期間記憶するモデル記憶部5180と、終端情報が格納された終端情報DB30と、関数モデルが格納された関数モデルDB50とに接続し、監視対象プロセス10の動作の正常/異常判定を行う装置であって、監視対象プロセスが利用するメモリ空間20、ソフトウェア識別子60、終端情報35、関数モデル55を利用して、判定した結果40を出力する。又、関数モデル5175をモデル記憶部5180に記録し、モデル記憶部5180に記録された関数モデル5185を取得して、廃棄命令5155を出力してモデル記憶部5180に記録された関数モデルをモデル記憶部5180から削除する。
【０１１３】
ソフトウェア動作監視装置5100は、システムコール発行検知部5110と、スタック情報取得部5120と、スタック差分情報生成部5130と、動作監視部5140と、モデル廃棄部5150と、終端情報取得部5160と、モデル取得部5170とを備える。
【０１１４】
システムコール発行検知部5110は、監視対象プロセス10がシステムコール15を発行したことを検知し、動作の検証がすむまで監視対象プロセス10を停止させ、検知情報5115をスタック情報取得部5120に伝える。検知情報5115は、スタック情報取得部5120を起動させるトリガとして利用すればよいので、例えば、スタック情報取得部5120の動作を管理するフラグがあったとして、そのビットを立てるとしてもよい。システムコール発行検知部5110は、例えば、Linux上のデバッグツールであるptraceを利用することで容易に実現できる。
【０１１５】
スタック情報取得部5120は、検知情報5115を受けると、監視対象プロセスが利用するメモリ空間20からコールスタックの状況25を取得し、さらに終端情報5165を利用し、スタック情報5125Aを生成する。生成したスタック情報5125Aはスタック差分情報生成部5130に伝えられる。スタック情報取得部5120は、コールスタックの状況25から、スタックフレームを探索し、スタックフレームを識別するスタックフレーム情報を順次取得する。スタックフレーム情報とは、例えば、復帰アドレスやカナリなどがあげられる。
【０１１６】
第３の実施形態では、復帰アドレスを用いてスタックフレームを識別するとして詳しく説明する。すなわち、スタック情報取得部5120は、コールスタックの状況25から各フレームに存在する復帰アドレスを順次取得する。抽出の仕方はいろいろあるが、x86やARMなどのコールスタックでは復帰アドレスはスタックフレームの最上位（底部の逆）に存在しているので、例えば、レジスタに保持されたスタックポインタとベースポインタを利用して、ベースポインタの直下の値を取得することで実現できる。スタック情報は、スタック情報記録部5120によってシステムコールが発行されたタイミングで、時系列順に記録される。又、スタック情報取得部5120は、終端情報5165（後に説明）によって復帰アドレス取得を中断し、終端到達情報5125Bをモデル廃棄部5150に伝えることを特徴とする。
【０１１７】
スタック差分情報生成部5130は、スタック情報5125Aを入力として、スタック差分情報、すなわち、pop情報5135A、push情報5135Bを生成する。スタック差分情報生成部5130では、システムコールi-1番目のスタック情報とシステムコールi番目のスタック情報から不一致部分を抽出し、得られた不一致部分を、pop情報、push情報として出力する。
【０１１８】
終端情報取得部5160は、終端情報DB30に記録されたi-1番目のスタック情報と、i番目のスタック情報とをコールスタックの底から順に比較し、コールスタックの位置と復帰アドレスが一致している部分を一致部分、異なる復帰アドレスを検知してから以降の部分を不一致部分とし、一致部分と不一致部分の境界である終端情報を取得する。図2は、スタック情報、一致部分、不一致部分、スタック差分情報、終端情報の例を示している。図2（a）で示すスタック情報を比較すると、一致部分が図2（b）、不一致部分が図2（c）となる。一致部分と不一致部分を分かつ復帰アドレスは“x”であるので、図2（e）のとおり、終端情報はxとなる。又、検証に利用するスタック差分情報とは、図2（d）のとおり、システムコールi番目の不一致部分のうち、システムコールi-1番目のスタック情報に存在した情報に終端情報を加えた情報をpop情報、システムコールi番目のスタック情報に存在した情報に終端情報を加えた情報をpush情報とすると、pop情報、push情報を総称した情報である。スタック差分情報を生成する際には、スタック情報から一致部分を除外し、不一致部分を抽出する処理を行う。この場合、スタック情報は底から検証する必要があるが、コールスタックの探索においては、スタックポインタがスタック上位（底と逆）に存在しているため、スタック上位から底に向かって探索が行われる。そのため、コールスタックに積まれたすべての復帰アドレスを取得する必要があるといえる。しかし、この終端情報は“除外すべき情報”と“抽出すべき情報”の境界に存在しているので、この終端情報を事前にリストアップして置き、コールスタックの探索時に利用することで、すべての復帰アドレスを取得することなく、中断できる。
【０１１９】
図16は関数モデルの例である。第３の実施形態に係る関数モデルは、ソースコードより、関数呼び出しの関係を抽出して生成したオートマトンである。関数モデルは関数ごとに存在し、節点は、（１）関数入り口（Entry）、（２）関数出口（Exit）、および（３）関数名の３種類のいずれかであり、節点への入り線は関数呼び出しとして、又節点からの出線は関数復帰として定義されるオートマトンである。図16（a）はソースコードの例、図16（b）はソースコードを解析して作られた関数モデルの例である。
【０１２０】
なお、関数モデルは、push、popの検証を行えればよいので、関数モデルの表現はオートマトンでなくてもよい。例えば、オートマトンの各節点に対して、ある節点を開始点として、ある節点を目的点とした場合に、開始点から目的点までの経路が存在するか否かを解析した結果を表で表現してもよい。図17は、図16（a)で示したソースコードから生成した、表形式で表現した関数モデルの例である。“○”は経路が存在することを、“×”は経路が存在しないことを表している。
【０１２１】
モデル取得部5170は、関数モデルDB 50から監視対象プロセス10の動作検証に適した関数モデルを取得して、モデル記憶部5180に記録する。後述するが、動作監視部5140は、pop情報、push情報のフレームごとに検査に適切な関数モデルを要求するので、モデル記憶部5180に必要な関数モデルがない場合に、関数モデルDB50から関数モデルを取得することとなる。又、モデル記憶部5180は、容量が多ければLRUアルゴリズムなどをもちいて管理することで、効率よい動作監視が可能となる。しかし、携帯電話などの組込み機器においては、モデル記憶部となるメモリの容量が限られているため、少ない容量でのモデルの管理が重要となる。又、モデル記憶部5180に記録する際、関数モデルに識別子を付与してもよい。後述するが、モデル記憶部5180に記録された関数モデルは、モデル廃棄部5150によって廃棄される可能性がある。このとき、廃棄対象の関数モデルを特定できるように、関数モデルに識別子を付与するとよい。図18（a）は、識別子が付与された関数モデルの例である。この例では、関数モデルであるオートマトンに、関数名“foo”を付与している。
【０１２２】
動作監視部5140は、スタック差分情報生成部5130が生成したpop情報5135A、push情報5135Bと、モデル記憶に記録されている関数モデル5185とを入力とし、pop情報、push情報と関数モデルとの乖離の有無を判定する。
【０１２３】
図19は、動作監視部5140の動作の例である。検証対象となるpop情報、push情報（図19（a））が入力されると、動作監視部5140は、pop情報、push情報が表す、コールスタックの状況を実現できる制御フローが関数モデル上に存在しているか否かを検証する。例えば、pop情報（図19（a）の(1)）の“q”については、rから復帰しqを終了できることを検証する。図19（b）はqの関数モデルである。ここで、節点rからExitまでのパスが存在しているかを検証する。図19（b）のとおり、qの関数モデルには、r→Exitのパスが存在しているため、qの検証結果は正常であったとする。もし、r→Exitのパスが存在しないようであれば、検証結果は異常であったとする。このように、sからxまで順次検証を行う。Popの動作が正常であった場合、pushの動作を検証する。この検証は、例えば、push情報（図19（a）の(2)）の“f”については、fへ入りgへといたることができるかを検証する。図19（c）は、fの関数モデルである。ここで、節点Entryから次のフレームのgにいたるまでのパスが存在しているかを検証する。図19（c）のとおり、fの関数モデルには、Entry→gのパスが存在しているので、fの検証結果は正常であったとする。もし、Entry→gのパスが存在しないようであれば、検証結果は異常であったとする。このように、push情報のxからhまで順次検証を行う。すべての検証において正常であると判定した場合にのみ、動作監視部140は、結果40として正常と出力する。
【０１２４】
このように、動作監視部5140では、pop情報、push情報の各フレームにおいて、必要な関数モデルを読み込み、パスを検証することになる。図19（d）は、push情報“h”を検証している際のモデル記憶部5180の状況である。ただし、モデル記憶部5180の管理はLRUアルゴリズムに則っていると仮定する。この時点でモデル記憶部5180には、今回の検証で利用した関数モデル以外にも、以前の検証で利用した関数モデルを保持している。
【０１２５】
終端情報取得部5160は、ソフトウェア識別子60と、終端情報35から、監視対象プロセス10に適した終端情報5165を取得し、スタック情報取得部5120に伝える。終端情報の概念は上述したが、一致部分と不一致部分を分ける復帰アドレスであり、監視対象ソフトウェアを事前に実行することにより得た終端情報のリスト（このリストを生成することを「事前学習」という。）は、コールスタックの探索を中断する情報として有用であると述べた。さらに、終端情報よりも底方向に存在するフレームは一致部分であり、動作監視部による検証が及ばないフレームである。このことを利用し、スタック取得部がコールスタックを探索している際に終端情報を検知した場合、それを契機にモデル記憶部5180に存在する、以前の検証で利用した関数モデルを消去してしまうことで、モデル記憶の残り容量を増やすことができる。特に、ソフトウェア動作監視装置5100が利用する終端情報は、事前学習の際に、ユーザから与えられるなどして設定されたしきい値以上の長さをもった期間、コールスタックの底からみて定位置に存在する終端情報である場合を考えると、その効果はさらに顕著になる。main関数を代表とするプログラム（あるいはモジュール）を統括する関数などは、コールスタックの定位置に存在する期間が長く、その位置よりも下位にある復帰アドレスはi番目のスタック情報とi-1番目のスタック情報で一致していることが多い。そのため、長い間定位置に存在する復帰アドレスは本来の終端情報である可能性が高い。このことから、終端情報は、一致部分と不一致部分の境界に存在する復帰アドレスでなくてもよく、コールスタックの定位置に存在する期間が長い復帰アドレスを終端情報として抽出してもよい。
【０１２６】
図20は、事前学習により得られたスタック情報の時系列の例である。スタック情報の中で、mainやX、aは、長い間定位置に存在した復帰アドレスである。このように終端情報として利用されたことがあり、定位置に連続して存在する復帰アドレスを終端情報として抽出する。このようにして得られた終端情報は、一致部分と不一致部分とを分ける位置に必ず存在するとは限らないが、終端情報よりも底方向にあるフレームには多くの一致部分が含まれている。すなわち、終端情報よりも底方向にあるフレームは、検証対象ではない可能性が非常に高い。さらに、この終端情報は一定期間同一のコールスタック位置に存在する復帰アドレスであるので、終端情報よりも底方向にあるフレームはある一定期間検証対象からははずされる。以上を考慮すると、終端情報よりも底方向にあるフレームの関数モデルはモデル記憶から消去しても大きな問題にはならないといえる。
【０１２７】
図21は終端情報を利用してスタック情報取得を中断し、終端到達情報を出力する例を示している。図21（a）は、終端情報取得部5160が取得した終端情報の例である。又、図21（b）は、ある時点でのコールスタックの状況の例である。システムコールが発行され、図21（b）上に示す、コールスタックの状況から、図21（b）下に示す、コールスタックの状況に遷移が起こった場合を考える。なお、コールスタックの状況には復帰アドレスだけでなく関数に渡される引数などが存在するが、説明を簡単にするために、復帰アドレスのみを示している。図21（b）上に示すコールスタックの状況から、スタック上位より復帰アドレスを順次取得していく。取得しながら、終端情報と比較をしていくと、終端情報と一致するxを検知する。この時点で、復帰アドレス取得を中断し、記録していた復帰アドレスを、xを含めてスタック情報として出力し、終端到達情報を出力する（図中のs,r,q,p,x）。図21（b）下に示すコールスタックの状況からも同様に、終端情報と一致するxを検知した時点で、復帰アドレス取得を中断し、記録していた復帰アドレスを、xを含めてスタック情報として出力し、終端到達情報を出力する（図中のh,g,f,x）。こうして得られたスタック情報は、次ステップであるスタック差分情報生成部5130によってスタック差分情報（pop情報、push情報）となる（図21（b）右）。
【０１２８】
モデル廃棄部5160は、終端到達情報5125Bを入力として受けると、モデル記憶部5180に格納されている関数モデルを消去する命令（廃棄命令5155）を出力し、モデル記憶部5180に格納されている関数モデルを消去する。消去対象の関数モデルは、モデル記憶部5180に存在している関数モデルすべてでもよいし、例えば、一時的にLRUアルゴリズムの閾値を変化させるなどして使用される頻度が少ないと判定された関数モデルというように選択してもよい。この消去対象の関数モデルを決定付けるのは、予め設計段階で設定してあってもよいし、ポリシー文書を用いるなどして外部から入力してもよい。なお、現在のメモリ使用量200を取得し、メモリ使用量に応じて、廃棄命令を出力するか否かを切り替えてもよい。又、関数モデルに識別子が付与されている場合、廃棄命令5155に廃棄対象の関数モデルの識別子を含めることで、廃棄対象を特定できる。図18（b）は、廃棄命令5155の例である。廃棄命令に廃棄対象の関数モデル識別子“foo”、“foo2”を伝える例（図18（b）下）、および、すべてが廃棄対象である意味の“all”を伝える例（図18（b）上）を示している。“foo”や“foo2”はハッシュ値を取ってもよい。その際、“all”は、関数モデル識別子と衝突しない値を取ってもよい。
【０１２９】
図22は、モデル廃棄部による関数モデルの廃棄の例である。ここでは消去対象はモデル記憶に存在しているモデルすべてとしている。図22（a）は、スタック情報取得部からの出力の例である。図18（a）の(1)、(2)は、それぞれ、i-1番目のスタック情報、i番目のスタック情報である。これらのスタック情報は、終端情報“x”の検知によって、コールスタックの探索が中断した結果得られた情報であるとする。すなわち、終端到達情報をうけ、終端到達フラグの状態がONになる(図18(a)の(3))。この状態でのモデル廃棄部の処理は、終端到達フラグによって、以前の検証で利用していた関数モデル“y”、“main”（図22（b）左）を、モデル記憶から廃棄する（図22（b）中）。以降、動作監視部によって関数モデルが要求されることで、モデル取得部によってモデル記憶に検証に必要な関数モデル“s”から“h”が格納される（図22（b）右）。
【０１３０】
図23は、モデル廃棄部が利用する廃棄ポリシーの例である。廃棄ポリシーは、ソフトウェア識別子、廃棄対象の列からなる表であって、ソフトウェアごとに廃棄対象を指定するようになっている。すなわち、ソフトウェア識別子“10”で示されるソフトウェアは廃棄対象をモデル記憶に存在している関数モデルすべてとし、ソフトウェア識別子70、30はLRUアルゴリズムの閾値を一時的に変更して、利用頻度の低い関数モデルを対象としている。閾値は、事前に動作させることで得られるソフトウェアの関数呼び出しの頻度分布から決定してもよい。分布では局所性が認められない場合に、廃棄対象をすべてとするとしてもよい。
【０１３１】
（ソフトウェア動作監視方法）
次に、第３の実施形態に係るソフトウェア動作監視方法について、図24及び図25を参照して説明する。
【０１３２】
まず、図24を参照して、スタック情報取得部5120の動作例について説明する。
【０１３３】
まず、スタック情報取得部5120は、終端情報取得部5160から終端情報を得る（ステップS5500）。コールスタックの状況25より、順次スタックフレームを取得し（ステップS5510）、当該スタックフレームの復帰アドレスを取得する（ステップS5520）。
【０１３４】
次に、スタック情報取得部5120は、終端情報を順次読み込み、ステップS5520で取得した復帰アドレスと終端情報とを比較する（ステップS5530）。ステップS5530は、終端情報が終わるまで、もしくは、復帰アドレスと終端情報との一致が確認されるまで続ける。終端情報が終わるまで一致が確認されなかったら、復帰アドレスをスタック情報として記録し（ステップS5540）、スタックフレームが終わるまでステップS5510からステップS5540までを繰り返す。ステップS5530で一致が確認された場合は、ループを抜け、終端情報を検知した旨を表す終端到達情報を出力し（ステップS5550）、スタック情報取得部を終了する。終端到達情報は、コールスタックの探索をしている際に終端情報を検知する旨を伝え、モデル廃棄部5150を起動するトリガとして利用すればよいので、例えば、モデル廃棄部5150の動作起動を管理するフラグがあったとして、そのビットを立てるとしてもよい。
【０１３５】
次に、図25を参照して、モデル廃棄部5160の動作例について説明する。
【０１３６】
まず、モデル廃棄部5160は、終端到達情報を受けた際に消去対象とする関数モデルを理解するための廃棄ポリシーを取得する（ステップS5100）。次に、監視対象プロセスが終了したことの検証と、終端到達情報を受けたことの検証を行い（それぞれ、ステップS5120、S5130）、どちらの事象も検知されなかった場合は、S5110からS5130までを繰り返す。
【０１３７】
ステップS5120で事象を検知した場合は、モデル廃棄処理を終了する。又、ステップS5130で事象を検知した場合は、現在のプロセスメモリ使用量を取得し（ステップS5140）、メモリ使用量がある閾値を超えたか否かを検証する（ステップS5150）。メモリ使用量が閾値を超えなかった場合は、ステップS5110へ戻り、閾値を超えた場合は、モデル記憶内の関数モデルを廃棄ポリシーに則って消去し（ステップS5160）、ステップS5110へ戻る。
【０１３８】
第３の実施形態では、消去対象関数モデルを決定するためにポリシーを利用するとしているが、予め定められている場合は、ポリシーを必要としない。その場合はステップS5100を除外してもよい。又、第３の実施形態では、メモリ使用量に応じて消去するか否かを判定するとしているが、メモリ使用量に応じない場合は、ステップS5140からS5150までを除外してもよい。
【０１３９】
（作用及び効果）
非特許文献１の手法を考慮すると、終端情報以降に現れるスタックフレーム情報で示される関数は、検証対象からはずされる。すなわち、この一致部分に存在する関数の関数モデルはメモリ上に存在していなくてもよい。そこで、第３の実施形態に係るソフトウェア動作監視装置は、コールスタックの探索の際に、終端情報とマッチする復帰アドレスの検知を契機に、コールスタックの探索を中断し、更にキャッシュに記録していた関数モデルを廃棄する。
【０１４０】
従って、第３の実施形態に係るソフトウェア動作監視装置によると、監視対象ソフトウェアの動作をソフトウェア実行中に監視する際、不要な関数モデルをメモリから排除することができるため、監視装置全体の空間オーバーヘッドを、時間オーバーヘッドを抑制した状態で削減することができる。又、メモリ上に残存した不要な関数モデルをメモリから排除することができ。使用メモリ量を抑えることができる．
関数モデルの廃棄は、次のシステムコール発生時のスタック差分情報の検証の際に必要となる関数モデルの廃棄をしてしまう恐れがある。そこで、終端情報取得部は、事前に取得したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することで，検証の際に、ある期間利用されない関数モデルのみを廃棄することができるので、終端情報に基づく関数モデルの廃棄に伴うリスクを軽減することができる。
【０１４１】
又、メモリの空き状況によっては、関数モデルを廃棄せずにLRUアルゴリズムなどでキャッシングしたほうが、時間オーバーヘッドを軽減できる可能性がある。そこで、モデル廃棄部は、現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えることで、必要な場合にのみ関数モデルを廃棄できるため、リスクを軽減することができる。
【０１４２】
又、特に、スタックフレーム情報は、復帰アドレスであることを特徴とすることで、コールスタックを修正することなく、スタックフレームを識別する情報を取得することができる。
【０１４３】
又、関数モデルをある期間記憶するモデル記憶（メモリ、キャッシュなど）に接続し、モデル取得部は、取得した関数モデルに識別子をつけてモデル記憶に記録し、モデル廃棄部は、識別子で廃棄する関数モデルを指定する廃棄命令をモデル記憶部に伝えることを特徴とすることで、廃棄する関数モデルを特定することができる。
【図面の簡単な説明】
【０１４４】
【図１】第１の実施形態に係るソフトウェア動作モデル化装置の構成ブロック図である。
【図２】第１の実施形態に係るスタック情報、スタック差分情報及び終端情報の例である。
【図３】第１の実施形態に係るスタック情報及び終端情報の例である（その１）。
【図４】第１の実施形態に係るスタック情報及び終端情報の例である（その２）。
【図５】第１の実施形態に係るソフトウェア動作モデル化方法を示すフローチャートである。
【図６】図５のS12の詳細を示すフローチャートである。
【図７】第１の実施形態に係る終端情報記録部が利用するリストの例である。
【図８】図５のS13の詳細を示すフローチャートである。
【図９】第１の実施形態に係るソフトウェア動作監視装置の構成ブロック図である。
【図１０】第１の実施形態に係る終端情報を利用してスタック情報取得を中断する例である（その１）。
【図１１】第１の実施形態に係る終端情報を利用してスタック情報取得を中断する例である（その２）。
【図１２】第１の実施形態に係るソフトウェア動作監視方法を示すフローチャートである。
【図１３】図１２のステップS22の詳細を示すフローチャートである。
【図１４】第２の実施形態に係るソフトウェア動作モデル化装置及びソフトウェア動作監視装置の構成ブロック図である。
【図１５】第３の実施形態に係るソフトウェア動作監視装置の構成ブロック図である。
【図１６】第３の実施形態に係る関数モデルの例である（その１）。
【図１７】第３の実施形態に係る関数モデルの例である（その２）。
【図１８】第３の実施形態に係る関数モデルと廃棄命令の例である。
【図１９】第３の実施形態に係る関数モデルを利用した動作監視の例である。
【図２０】第３の実施形態に係るスタック情報及び終端情報の例である。
【図２１】第３の実施形態に係る終端情報を利用してスタック情報取得を中断する例である。
【図２２】第３の実施形態に係る関数モデルの廃棄例である。
【図２３】第３の実施形態に係る廃棄ポリシーの例である。
【図２４】第３の実施形態に係るソフトウェア監視方法を示すフローチャートである（その１）。
【図２５】第３の実施形態に係るソフトウェア監視方法を示すフローチャートである（その２）。
【符号の説明】
【０１４５】
10…監視対象プロセス
15…システムコール
20…メモリ空間
25…コールスタックの状況
30…しきい値
35…終端情報
40…結果
50…モデル情報
55…関数モデル
70…ソフトウェア識別子
100…ソフトウェア動作モデル化装置
110…システムコール情報取得部
115…システムコール情報
120…スタック情報記録部
125…スタック情報
130…スタック差分情報生成部
135…スタック差分情報
140…モデル生成部
150…終端情報記録部
200…メモリ使用量
335…スタック差分情報
500…ソフトウェア動作監視装置
510…システムコール情報取得部
515A、515B…システムコール情報
520…スタック差分情報取得部
530…スタック差分情報生成部
530…動作モデル
535…スタック差分情報
540…動作監視部
550…終端情報取得部
555…終端情報
560…モデル取得部
565…モデル
1000…ソフトウェア動作監視装置
1010…システムコール取得部
1010…システムコール情報取得部
1020…スタック情報記録部
1030…スタック情報取得部
1040…スタック差分情報生成部
1050…モデル生成部
1055…モデル情報
1060…モデル取得部
1070…動作監視部
1080…終端情報記録部
1085…終端情報
1090…終端情報取得部
5100…ソフトウェア動作監視装置
5110…システムコール発行検知部
5115…検知情報
5120…スタック情報取得部
5120…スタック情報記録部
5125A…スタック情報
5125B…終端到達情報
5130…スタック差分情報生成部
5135A…pop情報
5135B…push情報
5140…動作監視部
5150…モデル廃棄部
5155…廃棄命令
5160…モデル廃棄部
5160…終端情報取得部
5165…終端情報
5170…モデル取得部
5175…関数モデル
5180…モデル記憶部
5185…関数モデル
【特許請求の範囲】
【請求項１】
ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するスタック情報記録部と、
iを自然数とし、前記スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とを、コールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録する終端情報記録部と、
前記終端情報記録部が記録した終端情報を用いて、前記スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成する第１のスタック差分情報生成部と、
前記スタック差分情報から、当該ソフトウェアの動作モデルを生成するモデル生成部と、
を備えることを特徴とするソフトウェア動作モデル化装置。
【請求項２】
前記終端情報記録部は、前記特定のイベントの識別子と終端情報の共起頻度の高い終端情報を、前記特定のイベントの識別子とともに記録し、
前記スタック差分情報生成部は、前記終端情報記録部が記録した終端情報から、特定のイベントの識別子を利用して、スタック差分情報の生成に用いる終端情報を取得することを特徴とする請求項１に記載のソフトウェア動作モデル化装置。
【請求項３】
前記終端情報記録部は、前記スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録することを特徴とする請求項１又は２に記載のソフトウェア動作モデル化装置。
【請求項４】
前記終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間の長さを把握し、前記期間が長いスタックフレーム情報を終端情報として記録することを特徴とする請求項３に記載のソフトウェア動作モデル化装置。
【請求項５】
前記モデル生成部によって生成された、監視対象となるソフトウェアの動作モデルを取得するモデル取得部と、
前記終端情報記録部によって記録された終端情報を取得する終端情報取得部と、
コールスタックを検索している際に、前記終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、
前記スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成する第２のスタック差分情報生成部と、
前記スタック差分情報生成部が生成した前記スタック差分情報と、前記モデル取得部が取得した前記動作モデルとの乖離を判定する動作監視部と
を更に備えることを特徴とする請求項１〜４のいずれか１項に記載のソフトウェア動作モデル化装置。
【請求項６】
前記スタックフレーム情報は、復帰アドレスであることを特徴とする請求項１〜５のいずれか１項に記載のソフトウェア動作モデル化装置。
【請求項７】
監視対象ソフトウェアが発行した特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを関数モデルとしたとき、監視対象のソフトウェアが発行した特定のイベントごとに、前記関数モデルを取得するモデル取得部と、
ソフトウェアの実行環境において、前記監視対象のソフトウェアに適した終端情報を取得する終端情報取得部と、
当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、前記終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、
前記スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するスタック差分情報生成部と、
前記スタック差分情報生成部が生成した前記スタック差分情報と、前記モデル取得部が取得した前記動作モデルとの乖離を判定する動作監視部と
を備えることを特徴とするソフトウェア動作監視装置。
【請求項８】
前記モデル取得部によって記録された関数モデルを廃棄するモデル廃棄部を更に備え、
前記モデル取得部は、事前に監視対象ソフトウェアのコードから関数ごとに生成した、関数相互の呼び出しの関係を示す関数モデルを取得し、
前記動作監視部は、前記スタック差分情報生成部によって生成されたスタック差分情報と、前記モデル取得部が取得した前記関数モデルとの乖離を判定し、
前記スタック情報取得部は，コールスタックからスタックフレーム情報を取得する際に、終端情報と一致するスタックフレーム情報を検知した場合に、スタックフレーム情報の取得を中断し、その場合、前記モデル廃棄部は、前記モデル取得部が以前のスタック差分情報の監視のために記録した関数モデルを廃棄することを特徴とする請求項７に記載のソフトウェア動作監視装置。
【請求項９】
前記終端情報取得部は、前記スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することを特徴とする請求項７又は８に記載のソフトウェア動作監視装置。
【請求項１０】
前記終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間が長いスタックフレーム情報を終端情報として記録した情報を取得することを特徴とする請求項９に記載のソフトウェア動作監視装置。
【請求項１１】
前記モデル廃棄部は、システムの現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えることを特徴とする請求項７〜１０のいずれか１項に記載のソフトウェア動作監視装置。
【請求項１２】
関数モデルを記憶するモデル記憶部を更に備え、
前記モデル取得部は、取得した関数モデルに識別子をつけて前記モデル記憶に記録し、
前記モデル廃棄部は、前記識別子で廃棄する関数モデルを指定する廃棄命令を前記モデル記憶部に伝えることを特徴とする請求項７〜１１のいずれか１項に記載のソフトウェア動作監視装置。
【請求項１３】
ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するステップと、
iを自然数とし、前記スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とを、コールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録するステップと、
前記終端情報記録部が記録した終端情報を用いて、前記スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成するステップと、
前記スタック差分情報から、当該ソフトウェアの動作モデルを生成するステップと
を含むことを特徴とするソフトウェア動作モデル化方法。
【請求項１４】
監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを取得するステップと、
ソフトウェアの実行環境において、前記監視対象のソフトウェアに適した終端情報を取得するステップと、
当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、前記終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するステップと、
前記スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するステップと、
前記スタック差分情報生成部が生成した前記スタック差分情報と、前記モデル取得部が取得した前記動作モデルとの乖離を判定するステップと
を含むことを特徴とするソフトウェア動作監視方法。
【請求項１】
ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するスタック情報記録部と、
iを自然数とし、前記スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とを、コールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録する終端情報記録部と、
前記終端情報記録部が記録した終端情報を用いて、前記スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成する第１のスタック差分情報生成部と、
前記スタック差分情報から、当該ソフトウェアの動作モデルを生成するモデル生成部と、
を備えることを特徴とするソフトウェア動作モデル化装置。
【請求項２】
前記終端情報記録部は、前記特定のイベントの識別子と終端情報の共起頻度の高い終端情報を、前記特定のイベントの識別子とともに記録し、
前記スタック差分情報生成部は、前記終端情報記録部が記録した終端情報から、特定のイベントの識別子を利用して、スタック差分情報の生成に用いる終端情報を取得することを特徴とする請求項１に記載のソフトウェア動作モデル化装置。
【請求項３】
前記終端情報記録部は、前記スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録することを特徴とする請求項１又は２に記載のソフトウェア動作モデル化装置。
【請求項４】
前記終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間の長さを把握し、前記期間が長いスタックフレーム情報を終端情報として記録することを特徴とする請求項３に記載のソフトウェア動作モデル化装置。
【請求項５】
前記モデル生成部によって生成された、監視対象となるソフトウェアの動作モデルを取得するモデル取得部と、
前記終端情報記録部によって記録された終端情報を取得する終端情報取得部と、
コールスタックを検索している際に、前記終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、
前記スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成する第２のスタック差分情報生成部と、
前記スタック差分情報生成部が生成した前記スタック差分情報と、前記モデル取得部が取得した前記動作モデルとの乖離を判定する動作監視部と
を更に備えることを特徴とする請求項１〜４のいずれか１項に記載のソフトウェア動作モデル化装置。
【請求項６】
前記スタックフレーム情報は、復帰アドレスであることを特徴とする請求項１〜５のいずれか１項に記載のソフトウェア動作モデル化装置。
【請求項７】
監視対象ソフトウェアが発行した特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを関数モデルとしたとき、監視対象のソフトウェアが発行した特定のイベントごとに、前記関数モデルを取得するモデル取得部と、
ソフトウェアの実行環境において、前記監視対象のソフトウェアに適した終端情報を取得する終端情報取得部と、
当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、前記終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するスタック情報取得部と、
前記スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するスタック差分情報生成部と、
前記スタック差分情報生成部が生成した前記スタック差分情報と、前記モデル取得部が取得した前記動作モデルとの乖離を判定する動作監視部と
を備えることを特徴とするソフトウェア動作監視装置。
【請求項８】
前記モデル取得部によって記録された関数モデルを廃棄するモデル廃棄部を更に備え、
前記モデル取得部は、事前に監視対象ソフトウェアのコードから関数ごとに生成した、関数相互の呼び出しの関係を示す関数モデルを取得し、
前記動作監視部は、前記スタック差分情報生成部によって生成されたスタック差分情報と、前記モデル取得部が取得した前記関数モデルとの乖離を判定し、
前記スタック情報取得部は，コールスタックからスタックフレーム情報を取得する際に、終端情報と一致するスタックフレーム情報を検知した場合に、スタックフレーム情報の取得を中断し、その場合、前記モデル廃棄部は、前記モデル取得部が以前のスタック差分情報の監視のために記録した関数モデルを廃棄することを特徴とする請求項７に記載のソフトウェア動作監視装置。
【請求項９】
前記終端情報取得部は、前記スタック情報記録部が記録したスタック情報の時系列から、任意の期間、コールスタックの底からみて定位置に存在するスタックフレーム情報を終端情報として記録した情報を取得することを特徴とする請求項７又は８に記載のソフトウェア動作監視装置。
【請求項１０】
前記終端情報記録部は、スタックフレーム情報がコールスタックの底からみて定位置に存在する期間が長いスタックフレーム情報を終端情報として記録した情報を取得することを特徴とする請求項９に記載のソフトウェア動作監視装置。
【請求項１１】
前記モデル廃棄部は、システムの現在の使用メモリ量を把握し、終端情報に基づく関数モデルの廃棄を行うか否かを切り替えることを特徴とする請求項７〜１０のいずれか１項に記載のソフトウェア動作監視装置。
【請求項１２】
関数モデルを記憶するモデル記憶部を更に備え、
前記モデル取得部は、取得した関数モデルに識別子をつけて前記モデル記憶に記録し、
前記モデル廃棄部は、前記識別子で廃棄する関数モデルを指定する廃棄命令を前記モデル記憶部に伝えることを特徴とする請求項７〜１１のいずれか１項に記載のソフトウェア動作監視装置。
【請求項１３】
ソフトウェアの実行環境において、ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得し、特定のイベント発生順に記録するステップと、
iを自然数とし、前記スタック情報記録部によって記録されたi-1番目のスタック情報とi番目のスタック情報とを、コールスタック底から順に比較して行き、コールスタックの位置とスタックフレーム情報が一致している部分を一致部分、異なるスタックフレーム情報を検知してから以降の部分を不一致部分とし、一致部分と不一致部分との境界をつくるスタックフレーム情報である終端情報を記録するステップと、
前記終端情報記録部が記録した終端情報を用いて、前記スタック情報のスタック上位から終端情報が検知されるまでの情報をお互い連結させた情報をスタック差分情報として生成するステップと、
前記スタック差分情報から、当該ソフトウェアの動作モデルを生成するステップと
を含むことを特徴とするソフトウェア動作モデル化方法。
【請求項１４】
監視対象のソフトウェアが発行した特定のイベントと、特定のイベントごとに、特定のイベント間で実行された関数呼出および任意で関数復帰の発行順との共起関係を示した動作モデルを取得するステップと、
ソフトウェアの実行環境において、前記監視対象のソフトウェアに適した終端情報を取得するステップと、
当該ソフトウェア実行中に、特定のイベントが発生した時点でのコールスタックに積まれたスタックフレームを識別するスタックフレーム情報を、コールスタックに積まれた順がわかるように取得するとともに、コールスタックを探索している際に、前記終端情報取得部によって伝えられた終端情報を検知した時点で、コールスタックからのスタックフレーム情報の取得を中断し、特定のイベント発生順に記録するステップと、
前記スタック情報取得部によって取得されたi-1番目のスタック情報とi番目のスタック情報をお互い連結させた情報をスタック差分情報として生成するステップと、
前記スタック差分情報生成部が生成した前記スタック差分情報と、前記モデル取得部が取得した前記動作モデルとの乖離を判定するステップと
を含むことを特徴とするソフトウェア動作監視方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００７−２８６６８６（Ｐ２００７−２８６６８６Ａ）
【公開日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願番号】特願２００６−１１００３６（Ｐ２００６−１１００３６）
【出願日】平成１８年４月１２日（２００６．４．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【出願人】（５０４１７１１３４）国立大学法人 筑波大学 (510)
【Ｆターム（参考）】
【公開日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願日】平成１８年４月１２日（２００６．４．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【出願人】（５０４１７１１３４）国立大学法人 筑波大学 (510)
【Ｆターム（参考）】
[ Back to top ]