JP2016538641A

JP2016538641A - アンチデバッグ方法

Info

Publication number: JP2016538641A
Application number: JP2016530187A
Authority: JP
Inventors: ナム、ゼ・ミン; パク、ジョン・グン; ホン、ジュン・ホ; オー、ジュン・ソク; キム、ジョン・ス
Original assignee: Inka Entworks Inc
Current assignee: Inka Entworks Inc
Priority date: 2013-11-14
Filing date: 2014-11-03
Publication date: 2016-12-08
Also published as: KR101519845B1; WO2015072689A1; US20160300044A1; CN105793860A

Abstract

アンチデバッグ方法を開示する。アンチデバッグ装置がアンチデバッグ（Anti-Debugging）を実行する方法において、子プロセス（Child Process）を生成する過程と、前記子プロセスで、親プロセス（Parent Process）の状態を監視する親プロセス監視過程と、前記親プロセスで、前記子プロセスの状態を監視する子プロセス監視過程とを含むことを特徴とするアンチデバッグ方法を提供する。【選択図】図６

Description

本発明は、プロセス状態を監視するアンチデバッグ方法に関するものである。

以下に記述される内容は、単に本実施例に係る背景情報のみを提供するだけで、従来技術を構成するものではないことを明らかにして置く。

ハッキングは、プログラムを分析することから始まる。プログラムを分析してロジックを把握することにより、実質的に操作（Crack）が可能となる。プログラムを分析する方法は2つの方法がある。一つは、静的（Static）分析方法であり、もう一つは、動的分析方法である。

静的分析方法は、プログラムファイルを実行せずにファイルのみ分析する。バイナリプログラムファイルを逆アセンブルツール（Tool）や逆コンパイルツールを用いて分析することである。これらのツールは、バイナリプログラムファイルをアセンブリ言語またはその他の高級言語形式に変換することができ、この変換されたアセンブリ言語などを分析すれば、プログラムのロジックを把握することができる。

動的（Dynamic）分析方法は、静的分析方法とは異なり、プログラムを実行させ、デバッグツールでプログラムの実行中であるコード（Code）の流れ、メモリ（Memory）の状態、レジスタ（Register）の状態などを見て、プログラムを分析する。デバッガを利用した分析方法は、実行中のコードの流れを見てプログラムを分析するため、プログラムのロジック（Logic）を把握しやすく、実際にコードが実行される部分とそうでない部分を判断することができるようになる。また、このような分析中にメモリやレジスタに保存された値を修正することもできる。

このようなデバッグによる分析方法は、プログラムの論理的な流れや実行中にデータをリアルタイムで変化させることができるなど、分析の範囲が静的分析方法より広く利用されている。

アンチデバッグ（Anti-Debugging）とは、デバッグを妨害して分析を防止する技術である。デバッグされた場合、そのデバッガプログラムを終了させるか、あるいはエラーを発生させる方法など、様々な方法を使用して分析を防止することができる。従来のアンチデバッグ技術は、主にデバッグプログラムが実行中であるか否かを確認して、デバッグ対象のプログラムが実行されないようにする。しかし、この方法によると、新しいデバッグプログラムなど、事前に予想していない状況が発生した場合に対処するのが難しいという問題点がある。また、特定のオペレーティングシステム（Operating System）やプロセッサ（Processor）に限られたアンチデバッグ技術が使用されており、例えば、ウィンドウズ（登録商標）（Windows（登録商標））オペレーティングシステムでは、ウィンドウズで提供するAPI（Application Program Interface）であるIsDebuggerPresent（）、CheckRemoteDebuggerPresent（）、及びNtGlobeFlag値を利用して、デバッグされたか否かを判断する方法が使用される。しかし、この方法では、リナックス（登録商標）（Linux（登録商標））、ユニックス（Unix（登録商標））、OS Xなどでは、これと同一または類似のAPIを提供していないため、使用することができないという問題点がある。

本実施例は、プロセスの状態を監視して、アンチデバッグ方法を提供することを主な目的とする。

本実施例の一側面によれば、アンチデバッグ装置がアンチデバッグ（Anti-Debugging）を実行する方法において、子プロセス（Child Process）を生成する過程と、前記子プロセスで、親プロセス（Parent Process）の状態を監視する親プロセス監視過程と、前記親プロセスで、前記子プロセスの状態を監視する子プロセス監視過程とを含むことを特徴とするアンチデバッグ方法を提供する。

また、本実施例の他の側面によれば、アンチデバッグ（Anti-Debugging）装置において、子プロセス（Child Process）を生成する子プロセス生成部と前記子プロセスの状態を監視する子プロセス監視部を含む親プロセスと、前記親プロセス（Parent Process）の状態を監視する親プロセス監視部を含む子プロセスとを含むことを特徴とするアンチデバッグ装置を提供する。

以上で説明したように、本実施例によれば、親（Parent）プロセス（Process）が子（Child）プロセスの状態をリアルタイム（Real-Time）で監視し、子プロセスが親プロセスの状態をリアルタイムで監視して、親プロセスや子プロセスがデバッグ状態、すなわち、追跡された（TracedまたはStopped）状態に転換した場合、すぐに親プロセスと子プロセスを強制終了させて、それ以上、デバッグ状態でプログラムが実行されることを防止することができる。

また、本実施例によれば、ゲームなどのハッキングに頻繁に使用されるメモリチート（Memory Cheat）プログラムの攻撃からプログラムを保護することができる。メモリチートプログラムの動作は、まず、攻撃対象のプログラムの状態を追跡された（TracedまたはStopped）状態に転換した後に行われるので、本発明の実施例によれば、プロセスが追跡された状態であることを検査して、追跡された状態であることが確認されたら、プロセスを終了するなどの措置をして、メモリチートプログラムの攻撃から防御することができる。

以下、本実施例を添付された図面を参照して詳細に説明する。本発明の技術的思想は、プロセス状態を監視することができる様々なシステムに適用することができ、特定のオペレーティングシステムやハードウェアに限定されない。

図1は、アンチデバッグを提供するコンピュータの構成図である。

図1は、親プロセスと子プロセスがデバッグされているかどうかのプロセス状態を相互に監視するアンチデバッグを提供するためのコンピュータ例である。補助記憶装置130に保存されていたプログラムが実行されると、プログラムはメインメモリ120にロードされて、中央処理装置（Central Processing Uni; CPU）110によって処理され、CPU110は、その処理結果をディスプレイ140に表示する。プログラムは、実行されると、自分と同じ形態の子プロセス（Child Process）を生成し（Fork）、自分は子プロセスの親プロセス（Parent Process）となる。親プロセスと子プロセスは、相互間に相手のプロセス状態を監視して、デバッグによるプログラムの分析を防ぐことができる。

図2は、プロセス制御ブロックの構成の例示図である。

プログラムが実行され、プロセス（Process）が生成されると、オペレーティングシステム（Operating System）は、内部にプロセスを管理するために必要な情報を保存し、これをプロセス制御ブロック（Process Control Block; PCB）200という。ただし、プロセス制御ブロックは、オペレーティングシステムに応じて別の名前で呼ばれることもある。プロセス制御ブロック200は、プロセス状態（Process State）210、プロセス識別子（Process ID）220、プログラムカウンタ230、レジスタ240、メモリ管理情報250、ファイル情報260などの情報を含むことができる。プロセス状態210には、生成（Created）、準備（Ready）、実行（Running）、待機（Waiting）、終了（Terminated）、追跡（Traced）などのプロセス状態を示す情報が保管される。プロセス識別子220には、システムの実行中であるプロセスを識別するための識別子情報が保管される。プログラムカウンタ230には、プロセスが次に実行する命令語のアドレス情報が保管される。レジスタ240には、CPUの動作に関連するレジスタ値が保管される。メモリ管理情報250には、プロセスのアドレス空間（Address Space）に関する情報が保管される。ファイル情報260には、プロセスが入力/出力するためにオープン（Open）している入力/出力装置とファイルの情報が保管される。

図3は、プロセスの状態遷移過程の例示図である。

図3は、プロセスが生成され、図2のプロセス制御ブロックに含まれているプロセス状態情報が転移される過程を表示する例示図である。補助記憶装置130に保存されていたプログラムが実行され、メインメモリ120にロードされ、プロセスが生成され、初期化過程を経る。このとき、プロセス制御ブロック200のプロセス状態値は、生成（NewまたはCreate）310に設定される。しかし、プロセスは生成されたものの、まだオペレーティングシステムによって実行可能な状態ではない。プロセスが実行されるためには、オペレーティングシステムのカーネル（Kernel）のキュー（Queue）でCPU割り当てを待機しなければならない。実行される準備をしていなければならない。この状態になると、プロセス状態値は、準備（Ready）320となる。プロセスは、キューで待機中、自分の番になると、CPU割り当てを受けて実行される。このとき、プロセス状態値は、実行中（Running）330となる。プロセスが実行中に入力/出力（Input/ Output; I/ O）が必要な状況が発生すると、入力/出力要求（I/ O Request）をシステムに送信し、プロセスは待機（Waiting）（340）状態になる。待機状態340で入力/出力が完了すると、再びプロセスが実行されるために準備状態320になり、自分の番になると、CPU割り当てを受けて、プロセスの状態は実行中（Running）330状態になる。プロセスが作業を完了すると、自分が占有していたすべてのリソース（Resource）をシステムに変換して終了する。プロセスが終了するために、自分のリソースをシステムに変換する時点の状態は消滅中（Terminated）350である。

プロセスが終了する前のいずれかの状態でデバッグのためにデバッガが付着（Attach）されると、プロセスの状態は追跡された（TracedまたはStopped）状態に遷移する（Transit）。また、デバッガ上でもプログラムを実行させることができ、このときに生成されたプロセスは追跡された状態となる。本発明の技術的思想は、このようなプロセスの状態遷移を把握してデバッグ状態を判別し、デバッグ状態と判別された場合、プロセスの実行を中断して、デバッグを通じたプログラムの分析ができないようにすることにある。これについては図4a、図4aで詳細に説明する。

図4aは、本実施例に係る親プロセスが子プロセスを監視する過程のフロー図である。

プログラムが実行され、メインメモリ120にロードされ、プロセスが生成される（S410）。生成されたプロセスはプログラムコードを共有し、別のアドレス空間（Address Space）を持つ子プロセスを生成する（S420）。このとき、子プロセスを生成したプロセスを親プロセスという。親プロセスは子プロセスの状態が追跡された（TracedまたはStopped）状態であるか否かを継続的に検査する（S430）。親プロセスが子プロセスを監視する過程は、プログラムが終了されない限り（S440）、継続的に実行する。GDB（Gnu Debugger）のようなデバッガは、デバッガでプログラムを実行させるか、あるいはすでに実行中のプロセスに付着（Attach）してプログラムをデバッグすることができる。また、メモリチート（Memory Cheat）プログラムも、プロセスの状態を追跡された状態に変更させた後、メモリチートプログラムが所望の場所のメモリ値を変更させる。子プロセスの状態が追跡された状態に変更された場合、子プロセスはデバッガ（Debugger）またはメモリチートプログラムなどの動的分析ツールによってプログラムが分析されていると判断することができる。プロセスの追跡された状態をデバッグ状態であると判断することができる理由は、デバッガを利用してそのプロセスをデバッグすると、プロセス状態が追跡された状態に変更される。プロセスが停止（Stopped）状態でプロセスにGDBのようなデバッガが付着されるか、あるいはデバッガでブレークポイント（Break Point）を設定してデバッグするときに、追跡された状態が表れる。したがって、追跡された状態をデバッグ状態であると判断することができる。

このように、プロセスが追跡された状態であれば、すぐにプロセスを中断することができ、プログラムが分析されることを防止することができる。また、親プロセスは子プロセスが終了したか否かを監視し、子プロセスの終了を発見した場合、親プロセスも終了する。

図4bは、本実施例に係る子プロセスが親プロセスを監視する過程のフロー図である。

親プロセスによって子プロセスが生成され（S450）、生成された子プロセスは、親プロセスの状態が追跡された状態であるか否かを継続的に検査する（S460）。親プロセスの状態が追跡された状態に変更された場合、子プロセスは、親プロセスがデバッガやメモリチートプログラムなどの動的分析ツールによってプログラムが分析されていると判断することができる。子プロセスが親プロセスを監視する過程は、プログラムが終了されない限り（S470）、継続的に実行する。もし、プログラムが分析されていると判断された場合、図4aと同様の方法で、親プロセスが終了されるので、プログラムが分析されることを防止することができる。また、子プロセスは、親プロセスが終了されたか否かを監視し、親プロセスの終了を発見した場合、子プロセスも終了する。

親プロセスと子プロセスを相互に監視するようにする理由は、親プロセスのみの場合は、親プロセス自身が追跡された状態に変更された場合、プロセスが停止状態であるため、何もすることができないからである。親プロセスのみの状態監視は、自分の追跡された状態を監視することができないが、本発明のように、親プロセスが子プロセスを生成して相互に監視すれば、一方が追跡された状態に変更された場合、他の一方のプロセスで変更されたプロセスを検知することができ、プロセスを中断することができる。

図5は、本実施例に係る親プロセスと子プロセスが相互に監視する状態の例示図である。

図5は、プログラムが実行され、親プロセス510が生成され（Create）、親プロセス510が子プロセス520を生成した（Fork）状態で、親プロセス510は、子プロセス520のプロセス状態を監視し、子プロセス520は、親プロセスの状態を監視する状態を示す例示である。

メインメモリ120で実行されている親プロセス510と子プロセス520は、常にペアになって、相互監視を行う。このうち一方のプロセスが終了されると、他方のプロセスも同様に終了されて、一方のプロセスが追跡された状態に変更された場合、他方のプロセスは変更されたプロセスを終了させ、自分も終了して、プログラムが分析されることを防止する。

図6は、本実施例に係るアンチデバッグ装置の構成図である。

アンチデバッグ装置600は、親プロセス610と子プロセス620を含む。親プロセス610は、子プロセス620を生成する子プロセス生成部612と、生成された子プロセス620のプロセス状態を監視する子プロセス監視部614と、親プロセスの状態情報を含む親プロセスを管理するための情報を保存するプロセス制御ブロック200とを含む。

子プロセス生成部612は、子プロセス620を生成した後、子プロセス620を監視するための別のスレッド（Thread）で、子プロセス監視部614を生成することができる。子プロセス監視部614は、子プロセス620の内部にあるプロセス制御ブロック200のプロセス状態情報が追跡された状態であるかを継続的に検査する。検査の結果、プロセスの状態情報が追跡された状態であることが確認されると、プログラムがデバッガやメモリチートプログラムなどによって分析されたものと判断して、親プロセス610と子プロセス620を終了する。また、子プロセス620が存在していない場合は、親プロセス610は終了する。また、子プロセスでも別のスレッドを生成して、親プロセスを監視することができる。

子プロセス620は、親プロセス610のプロセス状態を監視するための親プロセス監視部622と、子プロセスの状態情報を含むプロセスを管理するための情報を保存するプロセス制御ブロック200を含む。子プロセス620の親プロセス監視部622は、親プロセス610のプロセス制御ブロック200のプロセス状態が追跡された状態であるかを継続的に検査する。親プロセス監視部622は、子プロセス620内で、別のスレッド（Thread）で動作することができる。検査の結果、プロセス制御ブロック200のプロセスの状態情報が追跡された状態であることが確認されると、プログラムがデバッガやメモリチートプログラムなどによって分析されたものと判断して、親プロセス610と子プロセス620を終了する。また、親プロセス610が存在していない場合は、子プロセス620は終了する。

本発明の実施例に係るアンチデバッグ装置600は、パーソナルコンピュータ（PC：Personal Computer）、ノートブックコンピュータ、タブレット、個人携帯端末（PDA：Personal DigitalAssistant）、ゲームコンソール、携帯型マルチメディアプレーヤー（PMP：Portable Multimedia Player）、プレイステーションポータブル（PSP：PlayStation Portable）、無線通信端末（Wireless Communication Terminal）、スマートフォン（Smart Phone）、TV、メディアプレーヤーなどのユーザー端末である。本発明の実施例に係るアンチデバッグ装置600は、応用サーバーとサービスサーバーなどのサーバー端末である。本発明の実施例に係るアンチデバッグ装置600は、それぞれ、（i）各種機器や有線・無線通信網との通信を行うための通信モデムなどの通信装置、（ii）プログラムを実行するためのデータを保存するためのメモリ、（iii）プログラムを実行して演算および制御するためのマイクロプロセッサなどを備える様々な装置を意味することができる。少なくとも一実施例によれば、メモリはラム（Random Access Memory：RAM）、ロム（Read Only Memory：ROM）、フラッシュメモリ、光ディスク、磁気ディスク、ソリッドステートディスク（Solid State Disk：SSD）などのコンピュータで読み取り可能な記録/保存媒体である。少なくとも一実施例によれば、マイクロプロセッサは、明細書に記載された動作と機能を1つ以上選択的に実行するようにプログラムすることができる。少なくとも一実施例によれば、マイクロプロセッサは、全体または部分的に特定の構成の特定用途向け半導体（application specific integrated circuit：ASIC）などのハードウェアで具現される。

以上の説明は、本実施例の技術思想を例示的に説明したにすぎないものであって、本実施例の属する技術分野で通常の知識を有する者であれば、本実施例の本質的な特性から逸脱しない範囲で様々な修正および変形が可能である。したがって、本実施例は、本実施例の技術思想を限定するためのものではなく説明するためのものであり、これらの実施例により、本実施例の技術思想の範囲が限定されるものではない。本実施例の保護範囲は、特許請求の範囲によって解釈されるべきであり、それと同等の範囲内にあるすべての技術思想は、本実施例の権利範囲に含まれるものと解釈されるべきである。

図1は、アンチデバッグを提供するためのコンピュータの構成図である。図2は、プロセス制御ブロックの構成の例示図である。図3は、プロセスの状態遷移過程の例示図である。図4aは、本実施例に係る親プロセスが子プロセスを監視する過程のフロー図である。図4bは、本実施例に係る子プロセスが親プロセスを監視する過程のフロー図である。図5は、本実施例に係る親プロセスと子プロセスが相互に監視する状態の例示図である。図6は、本実施例に係るアンチデバッグ装置の構成図である。

Claims

アンチデバッグ装置がアンチデバッグ（Anti-Debugging）を実行する方法において、
子プロセス（Child Process）を生成する過程と、
前記子プロセスで、親プロセス（Parent Process）の状態を監視する親プロセス監視過程と、
前記親プロセスで、前記子プロセスの状態を監視する子プロセス監視過程とを含むことを特徴とするアンチデバッグ方法。
前記親プロセス監視過程は、
前記子プロセスで、前記親プロセスのプロセス制御ブロックでプロセス状態値（Value）を獲得する過程と、
前記親プロセスのプロセス状態値が追跡された（TracedまたはStopped）状態であるかを検査するプロセス状態検査過程とを含むことを特徴とする請求項１に記載のアンチデバッグ方法。
前記親プロセスの状態が追跡された状態である場合、親プロセスと子プロセスを終了する過程をさらに含むことを特徴とする請求項２に記載のアンチデバッグ方法。
前記親プロセスが終了された場合、前記子プロセスが終了する過程をさらに含むことを特徴とする請求項１に記載のアンチデバッグ方法。
前記子プロセス監視過程は、
前記親プロセスで、前記子プロセスのプロセス制御ブロックでプロセス状態値（Value）を獲得する過程と、
前記子プロセスのプロセス状態値が追跡された（TracedまたはStopped）状態であるかを検査するプロセス状態検査過程とを含むことを特徴とする請求項１に記載のアンチデバッグ方法。
前記子プロセスの状態が追跡された状態である場合、親プロセスと子プロセスが終了する過程をさらに含むことを特徴とする請求項５に記載のアンチデバッグ方法。
前記子プロセスが終了された場合、前記親プロセスが終了する過程をさらに含むことを特徴とする請求項１に記載のアンチデバッグ方法。
アンチデバッグ（Anti-Debugging）装置において、
子プロセス（Child Process）を生成する子プロセス生成部と、前記子プロセスの状態を監視する子プロセス監視部を含む親プロセスと、
前記親プロセス（Parent Process）の状態を監視する親プロセス監視部を含む子プロセスとを含むことを特徴とするアンチデバッグ装置。
前記親プロセスは、前記子プロセス監視部を別のスレッド（Thread）で生成することを特徴とする請求項８に記載のアンチデバッグ装置。
前記子プロセスは、前記親プロセス監視部を別のスレッド（Thread）で生成することを特徴とする請求項８に記載のアンチデバッグ装置。