JP2010509654A - コールスタックに記録された情報を用いたａｐｉの確認方法 - Google Patents

Abstract

コールスタックに記録された情報を用いてＡＰＩを確認する方法を提供する。【解決手段】アプリケーションのインストールされたシステムにおいて、前記アプリケーションの起動有無を確認するステップと、前記アプリケーションの起動時に要求されるＡＰＩ関数をフックするステップと、前記ＡＰＩ関数に対するコールスタックの内容を出力するステップと、出力されたコールスタックの内容を、前記アプリケーションの動作のための各種のＡＰＩ関数のコールスタックの内容を格納するスタックＤＢにおいて検索／確認するステップと、を含むことを特徴とする、スタックに記録された情報を用いたＡＰＩの確認方法。
【選択図】図１

Description

本発明はコールスタックに記録された情報を用いてアプリケーション・プログラム・インタフェース（ＡＰＩ： Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を確認する方法に関する。

周知の如く、スタックとは、処理の対象となる要請を格納するデータ格納先またはバッファを意味するものであって、ＩＢＭのコンピュータ用語辞書を見ると、スタックはプッシュダウン一覧であると記述されている。これは、新しい要請が入ると、古い要請を下に押しやるという意味である。このため、スタックは後入れ先出し（ＬＩＦＯ： ｌａｓｔ−ｉｎ ｆｉｒｓｔ−ｏｕｔ）の方式で動作する。

呼び出しスタックは、プロセスにより要請されるＡＰＩ関数による起動要請時に呼び出し関数の戻りアドレス、パラメータなどの内容をＬＩＦＯの規則に即して記録し、被呼び出し関数の終了時にスタックに格納された戻りアドレスに戻って作業を行い続ける。

一方、各種のアプリケーションがインストールされたシステム環境において、前記アプリケーションの制御と保安を実行可能な管理またはセキュリティプログラム（以下、「管理プログラム」と称する。）を作成するときには、当該アプリケーションとの緊密な連動が求められる。しかしながら、各アプリケーションは、これを開発した業体が技術保護などのために一般的にプログラムコードなどを公開しておらず、且つ、第３者による当該アプリケーションの構造分析にも限界があるため、第３者が各種のアプリケーションと緊密に連動する管理プログラムを作成・構成するには難点がある。

この難点により、管理プログラムの構造及び起動方式とほとんど同様の方式を有する侵入プログラム（ハッキングプログラム及びウィルスなど）が前記管理プログラムの監視を避けて許容されない作業をシステム内において行うことが可能になり、その結果、管理プログラムがシステムを厳しく管理するには限界がある。

一方、管理プログラムがアプリケーションとの連動のために用いられる最も一般的な方法としては、アプリケーションが使用する特定のＡＰＩ関数をフックして制御する方式があるが、この方式は、既存のＡＰＩ関数の起動を許容及び禁止したり、既存のＡＰＩ関数を管理プログラムのＡＰＩ関数に代替することによりなされていた。

従来の管理プログラムは、ＡＰＩ関数の上述した制御を目的に各関数を区別することを余儀なくされ、この区別は、関数のパラメータを確認することにより行われていた。しかしながら、この区別方式は、異なる目的（印加された遂行と、侵入及びハッキングなどのための未非印の遂行）をもって同じ動作をするＡＰＩ関数を区別することが困難であるという問題があった。

すなわち、アプリケーションの環境ファイルを変更時に、（１）アプリケーションそのものの環境ファイル変更プログラムを用いて正常に変更がなされる場合と、（２）ユーザーが任意に環境ファイルを作成して上書きする場合にそれぞれ用いられるＡＰＩ関数のパラメータが互いに同様であるため、従来の技術によっては、呼び出されたＡＰＩ関数の根本的な目的と用途を区別することができないということである。

これは、管理プログラムがアプリケーションと連動しながらこれを徹底して管理するのに限界となって、至急解決すべき課題であった。

本発明は上記の事情に鑑みてなされたものであり、その目的は、管理プログラムの起動根拠となる情報を侵入プログラムが制御できない範囲内において確認して、より効率的で信頼できるシステムの管理を安全に行うために、コールスタックに記録された情報を用いてＡＰＩを確認する方法を提供するところにある。

上記の技術的課題を達成するために、本発明は、アプリケーションのインストールされたシステムにおいて、前記アプリケーションの起動有無を確認するステップと、前記アプリケーションの起動時に要求されるＡＰＩ関数をフックするステップと、前記ＡＰＩ関数に対するコールスタックの内容を出力するステップと、出力されたコールスタックの内容を、前記アプリケーションの動作のための各種のＡＰＩ関数のコールスタックの内容を格納するスタック・データベース（ＤＢ）において検索／確認するステップと、を含むことを特徴とする、コールスタックに記録された情報を用いたＡＰＩの確認方法を提供する。

本発明によれば、システムにおいて任意のアプリケーションが行う作業に対する印加または非印加の有無を、ＡＰＩ関数による起動要請の内容確認により細かく確認することが可能になることから、アプリケーションの構造を精度よく分析することができ、しかも、システムにおける作動状態を完全に把握せずとも、前記アプリケーションにおいて行われる否定的な作動に対する制御をより細かく行うことができる。その結果、システムにおけるアプリケーションの作動を安定的に管理して、種々の方法により接近する各種の浸透プログラムの動作を無力化することが可能になる。

は、本発明によるＡＰＩの確認方法における動作の流れを示すフローチャートであり、 は、本発明によるＡＰＩの確認方法のシステム内における様子を示すブロック図であり、 は、スタックの様子を概念的に示す図である。

以下、添付図面に基づき、本発明を詳述する。

スタックとは、処理の対象となる要請を格納するデータ格納先またはバッファを意味するものであり、要請された資料がＬＩＦＯの方式で記録されて、スタックのトップを介して入力または削除される。これらの資料中には、オペレーティング・システム（ＯＳ）または各種のアプリケーションのロジックを行うためのＡＰＩ関数の起動要請内容が含まれ、本発明によるＡＰＩの確認方法は、スタックに記録された前記ＡＰＩ関数の起動要請の内容を読み込んで、現在システム（コンピュータ）が起動中の関数の用途または約束されていない動作の実行有無などを確認することができる。

図３は、スタックの様子を概念的に示す図であるが、以下、同図に基づき、本発明を説明する。

スタック１００は、プロセッサーに組み込まれたメモリーに位置し、一般的に、４バイト単位にて分離されたエリア１１０を有する。

ユーザーの操作により関数が呼び出されると、前記プロセッサーは、呼び出された関数を正常に起動するための記録を必要とし、このような記録は前記スタック１００のエリア１１０に順次に残される。

ＬＩＦＯ方式は、周知の如く、後に入ってきたコマンドまたは関数から先に取り出すような方式であり、前記スタック１００もＬＩＦＯ方式に即して動作する。このため、エリア１１０に記録される内容はスタック１００上において上から下へと記録され、動作は下から上へと行われる。なお、プロセッサーが次の動作を行うために確認しなければならないエリア１１０は、戻りアドレスにより確認する。

参考までに、スタック１００の各エリア１１０は固有のアドレスを有し、前記戻りアドレスには固有のアドレスが記録されるため、戻りアドレスに記録されたアドレスを探してプロセッサーの動作の流れを追跡することができる。

一方、ＥＢＰは、プロセッサーが行うべき動作を境界するものであり、規約により、前記ＥＢＰの古い（上位）エリアに前記戻りアドレスが記録される。

（参考資料１）

（参考資料２）

（参考資料１）は、パワーポイント（マイクロソフト社製作のアプリケーション）が自動的にパワーポイントファイル（＊．ｐｐｔ）に対するｄａｔａ．ｂａｋファイル（バックアップファイル）を生成するときにコールスタック（呼び出しスタック）に記録される起動要請内容であり、（参考資料２）は、ユーザーが任意にパワーポイントファイル（＊．ｐｐｔ）を＊．ｂａｋ拡張子にて格納するときにコールスタックに記録される起動要請内容であり、たとえ起動の最終結果が同じであるとしても、スタックに記録されるＡＰＩ関数の起動要請内容が異なってくる。このため、このような相違点を比較して前記ＡＰＩ関数の呼び出し理由を推定または確認することができる。

（参考資料１）及び（参考資料２）は、ｄａｔａ．ｂａｋファイルをどこにも格納できるように設定しておいた環境においてファイルを格納するためのＡＰＩ関数をフックすることにより得られたコールスタックであり、たとえ同じ結果を起動するとしても、異なる条件（パワーポイントが自動的にファイルを格納することと、ユーザーが任意にファイルを格納すること）においてはコールスタックに記録される起動要請内容に相違点があることを明示している。

もちろん、パワーポイントが自動的にファイルを格納する手順を行う場合には、たとえこの手順が多数回に亘って繰り返し行われるとしても、ＡＰＩ関数に対するコールスタックは同様である。

図１は、本発明によるＡＰＩの確認方法における動作の流れを示すフローチャートであり、図２は、本発明によるＡＰＩの確認方法のシステム内における様子を示すブロック図であるが、以下、これらの図に基づき、本発明を詳述する。

本発明によるＡＰＩの確認方法を適用することにより、多数のアプリケーションがインストールされたシステム内において前記アプリケーションの作動状態をより明確に確認・監督することができ、これにより、各種の侵入プログラムによる未印加システムの駆動及び誤作動などを予防することができる。

図１には、本発明によるＡＰＩの確認方法を適用した応用段階も示されており、本発明の実施形態を詳述するために、本発明によるＡＰＩの確認方法を段階別に説明する。

Ｓ１０：アプリケーションを起動するステップ
本発明によるＡＰＩの確認方法が適用及び応用された管理装置は、対象システムにおいて駆動するアプリケーションの起動有無を確認する。

すなわち、ユーザーが任意の課題を行うために必要となるアプリケーションを前記システムにおいて駆動すると、前記システムは、当該アプリケーションを起動しつつ、その起動がある旨を報知するデータを前記管理装置に送る。

Ｓ２０：起動アプリケーションを確認するステップ
管理装置は、現在起動中のアプリケーションを確認し、管理の登録されたアプリケーションであるかどうかを確認する。

ＡＰＩ関数のコールスタックは、たとえ同じＡＰＩ関数であるとしても、アプリケーションの種類によって、文字列として構成される起動要請の内容が異なってくるため、アプリケーションの種類によって適用されるレファレンス（（参考資料１）及び（参考資料２）などの起動要請内容の様子）が異なるように選択／適用される必要がある。このため、前記システムにおいて任意のアプリケーションが起動されれば、当該アプリケーションが管理装置に登録されてその管理が設定されたものであるかどうかが確認されなければならない。

Ｓ３０：起動アプリケーションコマンドを実行するステップ
一応、起動されたアプリケーションが管理装置の管理対象アプリケーションであると確認されれば、管理装置は、ユーザーまたはシステムから発生するコマンドにより前記アプリケーションが駆動しながら要請するＡＰＩ関数をリアルタイムにて確認する。

例えば、前記アプリケーションがワードプログラムの一種である「ハングル」である場合、ユーザー作成のドキュメントファイルの格納を前記「ハングル」により試みると、格納に必要となるＡＰＩ関数をシステムまたは前記「ハングル」のアプリケーションが要請し、当該ＡＰＩ関数は前記システムにより確認される。

図２を参照すると、前記アプリケーションは、コマンドを実行するために当該コマンドに相当する特定のＡＰＩ関数を呼び出している。

Ｓ４０：ＡＰＩ関数をフックするステップ
前記起動アプリケーションコマンドを実行するステップ（Ｓ３０）において確認されたＡＰＩ関数が、管理の登録されたＡＰＩ関数であるかを確認する。

このために、フック作業により当該動作を一時的に中止させ、任意の関数を呼び出す。図３に示すように、任意の関数であるＦ（変数６、変数７）を呼び出すと、当該関数に対する呼び出しの記録がスタック１００に残る。この状態において、変数７に対するアドレスを確認して、スタック１００において前記変数７が位置している正確なエリア１１０を確認する。一般的に、前記エリア１１０のアドレスまたは位置はＣ言語である（＆変数７）コマンドから確認することができる。

前記変数７のスタック１００内の位置が確認されれば、規約により記録されるスタック１００から変数７の位置を基準としてＥＢＰを探す。

続けて、前記ＥＢＰの真上エリアは以前に呼び出された関数の終了時に戻されるべきアドレスが記録されるエリアであるため、前記ＥＢＰの真上エリアから戻りアドレスを確認することができる。一方、ＥＢＰの内容（値）は、以前に自分を呼び出した関数のＥＢＰ値のアドレスを示す。もちろん、前記以前ＥＢＰの以前エリアはその以前呼び出し関数のＥＢＰを示すため、前記過程を繰り返し行うことにより、管理の登録されたＡＰＩ関数の起動時にスタック１００内の呼び出した全関数の戻りアドレスの記録をいずれも追跡することができる。

上述した追跡の結果は、既述したように、（参考資料１）及び（参考資料２）の内容である。

一方、アプリケーションは、その駆動のために数多くのＡＰＩ関数を必要とするが、これらの中には、アプリケーションを管理する上で不要となる関数も存在する。ところが、前記管理装置は、主としてシステムにファイルの形式で格納される情報を保安及び管理するのに適用される筈であるため、ファイルをコピーまたは移動するのに必要となるＡＰＩ関数が管理装置の主な追跡対象となる。

しかしながら、前記管理装置の追跡対象が必ずしもファイルのコピー及び移動などを行うＡＰＩ関数に限定されるとは限らない。

引き続き、要請されたＡＰＩ関数が管理の登録されたＡＰＩ関数であると確認されれば、当該ＡＰＩ関数をフックして前記ＡＰＩ関数の起動要請内容を出力する。ここで、前記ＡＰＩ関数の起動要請内容は、（参考資料１）または（参考資料２）の形式となる。

図２を参照すると、管理装置はフックを行いながら、先に要請されたＡＰＩ関数を代替する関数を呼び出す。すなわち、システムまたはアプリケーションは正常にＡＰＩ関数を呼び出すが、管理装置は、このような正常のＡＰＩ関数を代替するＡＰＩ関数を設けてシステムの処理に発生するエラーを防止し、次の作業を正常に行う。

Ｓ５０：スタックＤＢを検索するステップ
前記管理装置は、アプリケーション及びＡＰＩ関数別の起動要請内容を格納するスタックＤＢを含む。

上述したように、同じ条件下の同じＡＰＩ関数に対する起動要請の内容は一致するため、任意のアプリケーションにおいて行う各種の作業に対する当該ＡＰＩ関数の起動要請の内容を確認し、これをデータとして格納する。

すなわち、（参考資料１）のようにパワーポイントがファイルを自動的に格納するときのコールスタックの起動要請内容を確認してこれをテキストまたはイメージ形式などで前記スタックＤＢに格納し、この後、パワーポイント内においてファイルを格納するための作業を行うときに確認された起動要請内容を前記スタックＤＢに格納された対応する起動要請内容と比較して、同じであるか、それとも異なるっているかを確認する。

ここで、コールスタックに格納される当該ＡＰＩ関数の起動要請内容を見ると、当該ＡＰＩ関数の作業が行われる位置に関するディレクトリー情報（例：Ｃ:￥ＤＯＣＵＭＥ〜１￥ＡＬＬＵＳＥ〜１￥ＡＰＰＬＩＣ〜１￥ＭＩＣＲＯＳ〜1￥Ｏｆｆｉｃｅ￥Ｄａｔａ￥ＤＡＴＡ．ＢＡＫなど）と、英数字よりなる８桁文字（例：「０１１Ｂ００００」、「７Ｃ８０００００」など）で表わされるＤＬＬアドレスと、関数戻りアドレス（＋００００５Ｅ１Ａ、＋０００２７７５７、＋０００２７Ｂ６Ｂなど）と、当該ＡＰＩ関数の駆動のための各種の情報を有するＤＬＬ（ｄｙｎａｍｉｃ ｌｉｎｋ ｌｉｂｒａｒｙ）ファイル及びその位置（例：Ｃ:￥Ｐｒｏｄｕｃｔ￥ｂｉｎ￥ｖｓｄ￥ｖｓｄｐｗｐｎｔ．ｄｌｌなど）と、それぞれのパラメータ（例：（３Ａ４３,８０００００００,１,３,１）、（１３ＣＦ００,８０００００００,１,０,３）など）などから構成される。

ここで、前記パラメータは変数であるため変更可能であるが、関数戻りアドレスは、同じ環境において行われる同じ作業である場合には変更されないため、これを基準として当該ＡＰＩ関数の起動要請内容を比較することができる。

参考までに、前記ＤＬＬアドレス、ディレクトリー情報、ＤＬＬファイル及びその位置は実際にスタックに記録されず、これらの情報は本発明によるコールスタックに記録された情報を用いたＡＰＩの確認方法の駆動装置において編集して出力されたものである。

Ｓ６０：印加有無を確認するステップ。
前記スタックＤＢはＡＰＩ関数の許可された作業に対する起動要請の内容を格納するため、前記ＡＰＩ関数をフックするステップ（Ｓ４０）においてフックされたコールスタックの起動要請内容とスタックＤＢに格納された関連ＡＰＩ関数の起動要請内容とを比較し、その一致有無を確認する。

一般的に、許可されたＡＰＩ関数の起動要請内容は個別的に確認することによりその形態を知ることができ、侵入プログラムまたは未知の不正な方式によるＡＰＩ関数の起動要請内容は知られていないのがほとんどであるため、前記管理装置は、前記スタックＤＢに存在しないＡＰＩ関数の起動要請内容が前記ＡＰＩ関数フックステップ（Ｓ４０）において確認されれば、現在起動中のＡＰＩ関数の動作を未許可動作であると見なし、前記スタックＤＢに存在するものであると確認されれば、現在起動中のＡＰＩ関数の動作を許可された動作であると見なす。

もちろん、特定の侵入プログラムの動作だけを遮断するために、当該侵入プログラムのＡＰＩ関数の起動要請内容を前記スタックＤＢに格納しておき、前記侵入プログラムのＡＰＩ関数の起動要請内容と現在起動中のＡＰＩ関数の起動要請内容とを比較し、比較の結果、両者が同じであると確認されれば、これを制裁するようにしてもよい。

このため、たとえＡＰＩ関数をフックするステップ（Ｓ４０）において確認された起動要請内容が前記スタックＤＢにある起動要請内容と一致するとしても、常時印加された動作であると確認されるわけではない。

しかしながら、本発明による実施形態においては、スタックＤＢに存在しないＡＰＩ関数の起動要請内容がＡＰＩ関数をフックするステップ（Ｓ４０）において確認されれば、当該動作は未印加の動作であると見なす。このため、印加有無を確認するステップ（Ｓ６０）において確認されたスタックＤＢのＡＰＩ関数の起動要請内容と、ＡＰＩ関数をフックするステップ（Ｓ４０）において確認されたＡＰＩ関数の起動要請内容が一致する場合、当該動作は印加された動作であると見なし、スタックＤＢにおいて同じであることが確認できなかった場合には、当該動作が未印加の動作であると見なし、次の動作を行う。

Ｓ７０：パラメータを編集するステップ。
前記印加有無を確認するステップ（Ｓ６０）において、当該動作が未印加の動作であると確認されれば、同じ動作が繰り返し行われないように当該動作と関連するＡＰＩ関数の起動パラメータを修正して、今後同じ動作を行うために当該ＡＰＩ関数が呼び出されれば、パラメータの変更による正常の動作にバグを引き起こし、次のステップを行わないように遮断する。

図２を参照すると、当該動作が未印加の動作であると確認されても、ＡＰＩ関数のパラメータを編集することによりシステム及びアプリケーションが正常の動作を行わないようにしてもよく、システムまたはアプリケーションが要請した正常の特定ＡＰＩ関数を提供しないことにより、当該動作自体が最初から行われないようにしてもよい。

もちろん、前記印加有無を確認するステップ（Ｓ６０）において当該動作が印加された動作であると確認されれば、先に代替したＡＰＩ関数の代わりに正常の特定ＡＰＩ関数を提供する。

Claims (3)

1. アプリケーションのインストールされたシステムにおいて、前記アプリケーションの起動有無を確認するステップと、
   前記アプリケーションの起動時に要求されるアプリケーション・プログラム・インタフェース（ＡＰＩ）関数をフックするステップと、
   前記ＡＰＩ関数に対するコールスタックの内容を出力するステップと、
   出力されたコールスタックの内容を、前記アプリケーションの動作のための各種のＡＰＩ関数のコールスタックの内容を格納するスタック・データベース（ＤＢ）において検索／確認するステップと、
   を含むことを特徴とする、スタックに記録された情報を用いたＡＰＩの確認方法。
2. 前記アプリケーションの起動のために要求されたＡＰＩ関数がフックされれば、前記ＡＰＩ関数を代替する他のＡＰＩ関数を呼び出してシステムのエラー発生を防止するステップをさらに含むことを特徴とする、請求項１に記載のスタックに記録された情報を用いたＡＰＩの確認方法。
3. 前記スタックＤＢの検索結果、前記ＡＰＩ関数に対するコールスタックの内容が印加されたと確認されれば、ＡＰＩ関数に対する正常の作業を行い、印加されていないと確認されれば、ＡＰＩ関数の呼出を遮断したりＡＰＩ関数の変数を編集して正常の動作を遮断したりするステップをさらに含むことを特徴とする、請求項１または２に記載のスタックに記録された情報を用いたＡＰＩの確認方法。