JP6984760B2

JP6984760B2 - 変換装置及び変換プログラム

Info

Publication number: JP6984760B2
Application number: JP2020549948A
Authority: JP
Inventors: 裕平川古谷; 誠岩村; 潤三好
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2018-10-05
Filing date: 2019-05-20
Publication date: 2021-12-22
Anticipated expiration: 2039-05-20
Also published as: JPWO2020070918A1; US11748476B2; WO2020070918A1; US20210342444A1

Description

本発明は、変換装置及び変換プログラムに関する。

パターンマッチングは、特定のパターンをデータやログの中から見つけ出す技術である。このパターンマッチングは、セキュリティのあらゆる分野で応用されている。

例えば、ネットワーク侵入検知システム（ＩＤＳ（Intrusion Detection System））では、不正なトラフィックのパターンをシグネチャとして保持し、監視対象ネットワークを流れるデータがこのパターンを含んでいるかを調べることによって、不正なトラフィック、つまり攻撃者による攻撃や侵入を検知している。また、アンチウィルスでは、マルウェアの中に見られる特徴的なバイト列や文字列のパターンをシグネチャとして保持し、調査対象のファイルの中に、このシグネチャで記述されたパターンが含まれているかを調べることによって、マルウェアの検知を行っている。このように、大量のデータやそのデータを加工・記録したログの中から特定のパターンを見つける技術は、セキュリティの分野においても基本技術である。

このパターンマッチングを利用したシステムの検知精度、つまり、ＩＤＳやアンチウィルスの検知精度は、不正なトラフィックパターンやマルウェアに特徴的なバイト列や文字列を記述したシグネチャの正確性やその量に依存する。言い換えると、攻撃やマルウェアの種類を網羅するようにシグネチャを保持することができるならば、多くの攻撃や侵入やマルウェアを漏れなく検知することができるといえる。

世の中には様々なフォーマットのシグネチャが存在し、それぞれの利用用途やユースケースに応じた形で利用されている。ここでは、これらのシグネチャをプログラムとして実行可能なシグネチャ（プログラム形式のシグネチャ）と、プログラムとして実行できないシグネチャ（静的なシグネチャ）とに分類する。

プログラム形式のシグネチャとは、Ｃ言語、Ｐｙｔｈｏｎ、或いは、そのシグネチャを利用するソフトウェア・機器専用の言語によって記述されたシグネチャである。別の言い方をすると、命令型言語で書かれたものである。プログラム形式のシグネチャによれば、データやログを入力として受け取り、それらのデータやログに対する、特定の攻撃やマルウェアを検知するための条件を、プログラムとして記述することができる。プログラム形式のシグネチャによれば、プログラムとして記述することによって、各プログラム言語やそのライブラリが提供する豊富な機能を利用して検知条件を記述することができる。したがって、プログラム形式のシグネチャを用いることによって、開発のコストやメンテナンスのコストを高めることができる。

しかしながら、一方で、プログラム形式のシグネチャを利用するソフトウェア・機器は、そのプログラムの実行環境をソフトウェア・機器の内部に持つ必要がある。このため、プログラム形式のシグネチャは、利用できるソフトウェア・機器が特定のソフトウェア・機器に固定されやすく、特定のソフトウェア・機器上でのみ動作させることができるといった状況が生まれやすい。

一方、静的なシグネチャとは、データやログの中から見つけ出したいパターンや性質を記述したものであり、ＯｐｅｎＩＯＣやＣｙｂｏｘやＳｎｏｒｔなどがあり、宣言型言語で書かれたものも含んでいる。静的なシグネチャによれば、データやログを入力として受け取り、特定の攻撃やマルウェアを検知するための性質や特徴やパターンを記述することができる。静的なシグネチャによれば、検知のための特徴をパターンや性質として記述することによって、検知すべき対象を簡潔に記述できる。

ここで、この静的なシグネチャを利用するソフトウェア・機器はマッチングを行うエンジンを保持する必要があるものの、検知のためのロジックの簡潔さにより、プログラム形式のシグネチャのようにプログラム言語の実行環境を内部に保持することに比べれば、はるかにコストが低い。また、静的なシグネチャの場合には、パターンマッチングに特化させて実装することができるため、高速に動作することができる。このため、静的なシグネチャは、プログラム形式のシグネチャに比べ、より多くのソフトウェア・機器がサポートしていることが多い。

しかしながら、静的なシグネチャは、プログラム形式のシグネチャとは異なり、あらかじめ決められた範囲での検知ロジックしか利用できないため、詳細な検知ルールを記述するのは難しいという場合があった。

これらのシグネチャは、攻撃やマルウェアの特徴が記述された情報を含んでいるため、データとしての価値が高い。このため、シグネチャを脅威情報としてコミュニティ内で他者との交換や、それ自体を製品として販売するなどの取り組みが行われている。

一方で、同じ静的なシグネチャでも、そのフォーマットが異なる場合がある。このような場合、利用者はフォーマットを変換することによって、あるシグネチャを自身のソフトウェア・機器で利用できる形に変換する。この変換ツールは、ベンダや有志が公開している場合があり、これらを利用することによって、静的なシグネチャのフォーマットを自身が利用しているソフトウェア・機器でサポートしているフォーマットに変換し、利用することができる。

James C. King, "Symbolic Execution and Program Testing", Communications of the ACM CACM Homepage archive Volume 19 Issue 7, July 1976 Pages 385-394

このように、パターンマッチングを利用したシステムにおいて、シグネチャの精度が重要になる。また、そのシグネチャは、広くコミュニティで共有され、多くの人に利用されることが望ましい。仮に、あるシグネチャのフォーマットが、自身の利用しているソフトウェア・機器のフォーマットに合わなかった場合、フォーマット変換ツールを利用し、そのフォーマットを自身のソフトウェア・機器がサポートしているものに変換してから利用することができる。このため、シグネチャのフォーマットの変換は、重要な技術であるといえる。

この変換ツールのうち、静的なシグネチャを別の静的なシグネチャのフォーマットに変換する変換ツールは、前述のように、ベンダや有志により多く開発・公開されている。これに対し、プログラム形式のシグネチャを静的なシグネチャに変換するものは、ほとんど公開されていない。

仮に、プログラム形式のシグネチャを静的なシグネチャへ変換したい場合、そのドメインの知識を持った人間がそのプログラム形式のシグネチャを解析し、検知と判断するロジックを見極めた上で、手動で変換する必要がある。この方法では、ドメイン知識を持った人間が必要であり、また手動での変換のため大量の変換を行うことができないという問題がある。さらに、この方法では、複雑な検知ロジックになった場合、間違えが混入する可能性がある、といった問題がある。

一方で、静的なシグネチャをプログラム形式のシグネチャの中で利用するための変換は、比較的容易である。前述のように、静的なシグネチャは、その作りが原始的であるため、これらを解釈するパーサやマッチングエンジンが多く存在し、これらをライブラリとして提供している場合が多い。プログラム形式のシグネチャは、これらのライブラリをインポートし呼び出すだけで、これら静的なシグネチャを自身の中に取り込むことができる。このため、この静的シグネチャからプログラム形式のシグネチャへの変換は大きな問題にはなっていない。

上述のような理由により、プログラム形式のシグネチャを使用する場合、プログラム形式のシグネチャを利用できるソフトウェア・機器が固定されやすいことに加え、プログラム形式のシグネチャに関する知識が広くコミュニティで共有されない、或いは、活用されない、といった問題があった。

本発明は、上記に鑑みてなされたものであって、プログラム形式のシグネチャを静的なシグネチャに自動的に変換することができる変換装置及び変換プログラムを提供することを目的とする。

本発明の変換装置は、解析対象であるプログラム形式のシグネチャと、入力値であるシンボル化されたデータ・ログとの入力を受け付けると、シンボリック実行エンジンを利用してプログラム形式のシグネチャを解析し、入力値に対して行う条件分岐の処理を、入力値に対する制約として出力する実行部と、出力された入力値に対する制約が入力されると、各フォーマット間のフィールド対応表に基づいて、入力値に対する制約と出力先フォーマットのフィールド変換を行い、静的なシグネチャを出力する変換部と、を有することを特徴とする。

本発明によれば、プログラム形式のシグネチャを静的なシグネチャに自動的に変換することができる。

図１は、実施の形態に係る変換装置の構成の一例を模式的に示す図である。図２は、シンボリック実行部及び変換部の処理の流れを説明する図である。図３は、プログラム形式のシグネチャの一例を示す図である。図４は、フィールド変換表の一例を示す図である。図５は、演算子変換表の一例を示す図である。図６は、実施の形態に係る変換方法の処理手順を示すフローチャートである。図７は、プログラムが実行されることにより変換装置が実現されるコンピュータの一例を示す図である。

以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

［実施の形態］
本発明の実施の形態について説明する。本発明の実施の形態に係る変換装置では、シンボリック実行（例えば、非特許文献１参照）を用いて、プログラム形式のシグネチャを解析し、そのシグネチャが検知と判断する条件を抽出する。

このため、変換装置は、まずプログラム形式のシグネチャが検査対象としているデータ及び／またはログ（以降、データ・ログとする。）をシンボル化する。次に、変換装置は、このシンボル化したデータ・ログを入力としてプログラム形式のシグネチャに渡し、このプログラム形式のシグネチャをシンボリック実行エンジン上で実行し、解析する。変換装置は、この解析中に、プログラム形式のシグネチャが、入力値の値による条件分岐（if文など）を実行しようとした場合、その条件分岐の条件が成立する場合と成立しない場合とを考え、それぞれの場合を取るための入力値に対する制約を算出し、それぞれのパスの実行条件として加える。

変換装置は、この処理を、プログラム形式のシグネチャが「検知」、または、「検知でない」と最終的に判断するまで続ける。これにより、変換装置は、「検知」と判断するまでの入力値に対する制約、または、「検知でない」と判断するまでの入力値に対する制約を、論理式の形で取得することができる。この「検知」と判断するまでの入力値に対する制約の集合は、元のプログラム形式のシグネチャで記述されていた「検知」と判断するロジックに比べ、原始的な表現で表される。このため、入力値に対する制約の集合は、他のフォーマット、表現形式に容易に変換することができる。

［変換装置の構成］
具体的に、本実施の形態に係る変換装置について説明する。図１は、実施の形態に係る変換装置の構成の一例を模式的に示す図である。

図１に示すように、変換装置１０は、通信部１１、入力部１２、出力部１３、記憶部１４及び制御部１５を有する。本変換装置１０は、ＩＤＳやアンチウィルスなどのシグネチャを作成する人、またはそれらを利用するソフトウェア・機器を運用或いは利用する人による利用を想定している。

通信部１１は、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースである。通信部１１は、ＮＩＣ（Network Interface Card）等で実現され、ＬＡＮ（Local Area Network）やインターネットなどの電気通信回線を介した他の装置と制御部１５との間の通信を行う。例えば、通信部１１は、ネットワークＮなどを介して入力された、シンボル化されたデータ・ログや、プログラム形式のシグネチャを制御部１５に入力する。そして、通信部１１は、プログラム形式のシグネチャが変換された静的なシグネチャを、ネットワークＮ等を介して、他の装置に送信する。なお、シンボル化されたデータ・ログは、プログラム形式のシグネチャが検査対象としているデータ・ログをシンボル化したものである。

入力部１２は、変換装置１０の操作者からの各種操作を受け付ける入力インタフェースである。例えば、入力部１２は、タッチパネル、音声入力デバイス、キーボードやマウス等の入力デバイスによって構成される。

出力部１３は、例えば、液晶ディスプレイなどの表示装置、プリンター等の印刷装置、情報通信装置等によって実現される。出力部１３は、プログラム形式のシグネチャの変換処理に関する情報等を操作者に対して出力する。

記憶部１４は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置によって実現され、変換装置１０を動作させる処理プログラムや、処理プログラムの実行中に使用されるデータなどが記憶される。記憶部１４は、各フォーマット間のフィールド対応表を記憶する。

制御部１５は、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。例えば、制御部１５は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路である。制御部１５は、シンボリック実行部１５１（実行部）及び変換部１５２を有する。

シンボリック実行部１５１は、解析対象であるプログラム形式のシグネチャと、入力値であるシンボル化されたデータ・ログとの入力を受け付けると、シンボリック実行エンジンを利用してプログラム形式のシグネチャを解析し、入力値に対して行う条件分岐の処理を、入力値に対する制約として出力する。

変換部１５２は、出力された入力値に対する制約が入力されると、各フォーマット間のフィールド対応表に基づいて、入力値に対する制約と出力先フォーマットのフィールド変換を行い、静的なシグネチャを出力する。すなわち、入力されたプログラム形式のシグネチャを変換した静的なシグネチャが、変換装置１０から出力される。

［変換処理の流れ］
次に、シンボリック実行部１５１及び変換部１５２における変換処理の流れについて説明する。図２は、シンボリック実行部１５１及び変換部１５２の処理の流れを説明する図である。

シンボリック実行部１５１は、解析対象であるプログラム形式のシグネチャを、シンボリック実行を利用して解析する機能を有する。図２に示すように、シンボリック実行部１５１は、入力として、プログラム形式のシグネチャＧａと、プログラム形式のシグネチャが入力として受け取るシンボル化されたデータ・ログＧｂとを受け取る。

まず、シンボル化されたデータ・ログＧｂに関して説明する。プログラム形式のシグネチャは、トラフィックやファイルのデータストリームなどのデータや、それらの情報を加工したログの中から、攻撃やマルウェアの持つ特徴的な条件に合致する部分が存在するかを検査するものである。今回の解析の中で抽出するものは、プログラム形式のシグネチャ側が持つ、検知と判断するために、入力値が満たすべき条件である。このため、変換装置１０では、このプログラム形式のシグネチャに入力する値を特定の値に固定せずに、あらゆる値を取れるシンボルとして入力する。

シンボリック実行部１５１では、このシンボル化されたデータ・ログＧｂを用いて、プログラム形式のシグネチャＧａを、シンボリック実行を使って解析する。シンボリック実行部１５１は、このシンボリック実行による解析を行うことによって、このプログラム形式のシグネチャＧａが、「検知」と判断するまで、シンボル化されたデータに対して行う条件分岐の処理を、入力値に対する制約という形で抽出する。

次に、シンボリック実行部１５１で出力された、シンボル化されたデータ・ログに対する制約Ｇｃを変換部１５２に入力する。変換部１５２では、各フォーマット間のフィールドの対応表Ｇｄに基づき、入力された制約と出力先フォーマットのフィールドの変換を行う。各フォーマット間のフィールドの対応表Ｇｄは、例えば、入力元フォーマットの文法・表現と、出力先フォーマットの文法・表現とを対応付けた表である。この際、入力された制約と出力先フォーマットに記述文法の違いがあれば、変換部１５２は、これらを吸収するように変換を行う。最後に、変換部１５２は、目的のフォーマットに変換された静的なシグネチャＧｅを出力して、処理を終了する。

［シンボリック実行部の処理例］
次に、具体的な例を参照して、シンボリック実行部１５１の処理を説明する。なお、ここでの例は、説明のために定義しているものであり、変換装置１０の処理動作がこれらの例に限定されているわけではない。例えば、シンボリック実行エンジンの実装やプログラム言語の種類、シンボル化されたデータ・ログのフォーマット、静的シグネチャのフォーマットなどには本実施の形態は、依存しない。

図３は、プログラム形式のシグネチャの一例を示す図である。この例では、シンボリック実行部１５１が、プログラムを解析し、その挙動を取得する解析を行った後、そのプログラムが行った挙動と、予め悪意のある挙動を定義したシグネチャとのマッチングを行う。

図３のうち、「accessed_regkey_logs」と「accessed_file_logs」とは、シンボル化されたデータ・ログが格納されたリスト構造である。それぞれのシンボル変数の名前を、「sym_regkey」及び「sym_file」とする。これらの配列の中に「xyz」というレジストリキー、または、「abc」というファイル名の両方が含まれている場合、このプログラム形式のシグネチャは、「検知」と判断し、「True」を返す。そして、どちらか一方しか検知しない、または、どちらも検知しなかった場合、このプログラム形式のプログラムは「検知なし」と判断し、「False」を返す。

シンボリック実行部１５１は、このプログラム形式のシグネチャを実行する。シンボリック実行部１５１は、途中、２行目で条件分岐に当たるため、ここで、この２行目の条件を満たす場合と、２行目の条件を満たさない場合と、の制約を、それぞれのパスに加える。つまり、シンボリック実行部１５１は、２行目→３行目を実行するパス、つまり、この条件分岐で真の場合には、「sym_regkey==“xyz”」の制約２行目→４行目を実行するパス、すなわち、この条件分岐で偽になる場合には、「Not(sym_regkey==“xyz”)」の制約を加える。

それぞれのパスで実行を続けると、次は６行目で、再び条件分岐に当たる。ここで再度、この条件を満たす場合と満たさない場合の制約をそれぞれのパスに加える。すなわち、シンボリック実行部１５１は、６行目→７行目を実行するパスには、「sym_file==“abc”」の制約を、６行目→８行目を実行するパスには、「Not(sym_file==“abc”)」の制約を加える。

以上をまとめると、シンボリック実行部１５１は、図３に示すプログラム形式のシグネチャをシンボリック実行した場合、以下の第１〜第４の４つのパスを得ることができる。なお、説明を簡潔にするため、「accessed_regkey_logs」と「accessed_file_logs」との配列には、それぞれ、「sym_regkey」と「sym_file」の１つの要素しか含まれていないものとする。

第１のパス：1→2→3→4→5→6→7→8→9→10
第２のパス：1→2→3→4→5→6→8→9→11→12
第３のパス：1→2→4→5→6→7→8→9→11→12
第４のパス：1→2→4→5→6→8→9→11→12

この４つのパスのうち、「検知」と判断し、「True」を返すパスは、第１のパスのみである。このため、シンボリック実行部１５１は、この第１のパスを実行した時の制約である「sym_regkey==“xyz”∧sym_file==“abc”」を変換部１５２に入力する。なお、シンボリック実行部１５１は、シンボリック実行の際、「検知」と判断するパスが複数存在していた場合、それらの制約を「∨」でつないだものを出力とする。

［変換部の処理例］
次に、具体的な例を参照して、変換部１５２の処理を説明する。変換部１５２は、制約の中のシンボル変数名と、変換先フォーマットのフィールド名の対応表とに基づき、フィールドの変換を行う。また、変換部１５２は、フィールドと値の評価を行う演算子も、変換先のフォーマットに従って変換を行う。

図４は、フィールド変換表の一例を示す図である。図５は、演算子変換表の一例を示す図である。図４のフィールド変換表は、シンボル変数名と、変換先フィールドとを対応付けたテーブルである。また、図５の演算子変換表は、変換元演算子と、変換先演算子とを対応付けたテーブルである。変換部１５２は、このようなフィールド変換表や演算子変換表を含む変換先フォーマットのフィールド名の対応表を用いて、フィールドの変換を行う。

変換部１５２は、図４に示すフィールド変換表や、図５に示す演算子変換表を用いて、変換を行う。具体的には、変換部１５２は、フィールド変換表の行Ｒ１，Ｒ２及び演算子変換表の行Ｒ３を基に、「sym_regkey==“xyz”∧sym_file==“abc”」を、「RegkeyItem is “xyz” and FileItem is “abc”」と変換する。そして、変換部１５２は、この「RegkeyItem is “xyz” and "FileItem is “abc”」を出力としてファイル等に書き出す。

このように、変換部１５２は、入力値に対する制約の中のシンボル変数名と、各フォーマット間のフィールド対応表のうち出力先フォーマットのフィールド名の対応表とを基にフィールドの変換を行う。

［変換処理］
次に、変換装置１０が実行する変換処理の流れについて説明する。図６は、実施の形態に係る変換方法の処理手順を示すフローチャートである。

図６に示すように、まず、シンボリック実行部１５１は、解析対象であるプログラム形式のシグネチャと、入力値であるシンボル化されたデータ・ログとの入力を受け付ける（ステップＳ１，Ｓ２）。続いて、シンボリック実行部１５１は、シンボリック実行エンジンを利用してプログラム形式のシグネチャを解析し、入力値に対して行う条件分岐の処理を、入力値に対する制約として出力するシンボリック実行処理を行う（ステップＳ３）。

そして、変換部１５２は、シンボリック実行部１５１から出力された入力値に対する制約が入力されると、各フォーマット間のフィールド対応表に基づいて、入力値に対する制約と出力先フォーマットのフィールド変換を行う変換処理を行う（ステップＳ４）。そして、変換部１５２は、プログラム形式のシグネチャを変換した静的なシグネチャを出力して（ステップＳ５）、処理を終了する。

［実施の形態の効果］
このように、本実施の形態に係る変換装置１０は、解析対象であるプログラム形式のシグネチャと、入力値であるシンボル化されたデータ・ログとの入力を受け付けると、シンボリック実行エンジンを利用してプログラム形式のシグネチャを解析し、入力値に対して行う条件分岐の処理を、入力値に対する制約として出力する。続いて、変換装置１０は、入力値に対する制約が入力されると、各フォーマット間のフィールド対応表に基づいて、入力値に対する制約と出力先フォーマットのフィールド変換を行い、静的なシグネチャを出力する。

したがって、本実施の形態によれば、プログラム形式のシグネチャを静的なシグネチャに自動的に変換することができる。すわなち、本実施の形態によれば、ソフトウェア・機器に固有になりがちだったプログラム形式のシグネチャを、静的なシグネチャしか対応していないソフトウェア・機器で利用することができる。このため、本実施の形態によれば、シグネチャとして書かれた攻撃やマルウェアに関する知識・ノウハウを広く利用することが可能になる。

さらに、本実施の形態の変換装置１０を用いることによって、静的なシグネチャしか対応していないソフトウェア・機器の利用者でも、プログラム言語を利用してシグネチャの開発をすることができる。前述のように、プログラム形式のシグネチャは、豊富な機能やライブラリを持つプログラム言語を利用して記述することができる。このため、本実施の形態の変換装置１０を用いることによって、詳細な検知条件を記述できる上、その開発コストを低く抑えることができる。

なお、本実施の形態は、上述した悪意のある挙動を見つけ出すといったユースケース以外にも、例えば、ネットワークトラフィックやそのログをシンボル化して、攻撃者による攻撃や侵入を検知するシグネチャをシンボリック実行で解析して、検知条件を抽出する、場合にも適用できる。

その他にも、本実施の形態は、ファイルのバイトストリームやヘッダ情報や文字列情報等をシンボル化して、マルウェアを検知するシグネチャをシンボリック実行で解析し、検知条件を抽出する場合にも適用できる。

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

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

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

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

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、変換装置１０の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、変換装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid State Drive）により代替されてもよい。

また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

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

以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等は全て本発明の範疇に含まれる。

１０変換装置
１１通信部
１２入力部
１３出力部
１４記憶部
１５制御部
１５１シンボリック実行部
１５２変換部

Claims

解析対象であるプログラム形式のシグネチャと、入力値であるシンボル化されたデータ・ログとの入力を受け付けると、シンボリック実行エンジンを利用してプログラム形式のシグネチャを解析し、前記入力値に対して行う条件分岐の処理を、入力値に対する制約として出力する実行部と、
出力された前記入力値に対する制約が入力されると、各フォーマット間のフィールド対応表に基づいて、前記入力値に対する制約と出力先フォーマットのフィールド変換を行い、静的なシグネチャを出力する変換部と、
を有することを特徴とする変換装置。
前記実行部は、前記プログラム形式のシグネチャが検知と判断するまで、シンボル化されたデータに対して行う条件分岐の処理を、前記入力値に対する制約とする形式で出力することを特徴とする請求項１に記載の変換装置。
前記変換部は、前記入力値に対する制約の中のシンボル変数名と、各フォーマット間のフィールド対応表のうち前記出力先フォーマットのフィールド名の対応表とを基にフィールドの変換を行うことを特徴とする請求項１または２に記載の変換装置。
解析対象であるプログラム形式のシグネチャと、入力値であるシンボル化されたデータ・ログとの入力を受け付けると、シンボリック実行エンジンを利用してプログラム形式のシグネチャを解析し、前記入力値に対して行う条件分岐の処理を、入力値に対する制約として出力するステップと、
出力された前記入力値に対する制約が入力されると、各フォーマット間のフィールド対応表に基づいて、前記入力値に対する制約と出力先フォーマットのフィールド変換を行い、静的なシグネチャを出力するステップと、
をコンピュータに実行させるための変換プログラム。