JP2019537150A - セルフデバッギング - Google Patents

Abstract

大まかに言うと、ソフトウェアを保護するための方法、コンピュータプログラム製品、及び装置が提供される。本開示に従って、方法は、デバッガプロセスをソフトウェアプロセスにアタッチすることを含むことができる。ソフトウェアプロセスの実行中に、コードプロセスの機能に関連する動作は、デバッガプロセス中に実行される。その結果、デバッガプロセスは、ソフトウェアプロセスの機能に影響を与えずに置き換えられるか又は損なわれることがありえない。ソフトウェアプロセスは、従って、変更されたか悪意のあるデバッギング技術による検査から保護できる。【選択図】図１

Description

本開示につながる研究は、承認契約ｎ°６０９７３４の下で［欧州連合］［欧州原子力共同体］第７フレームワークプログラム（［ＦＰ７／２００７−２０１３］［ＦＰ７／２００７−２０１１］）から資金提供を受けたものである。

本開示は、ソフトウェアセキュリティ、詳細には、デバッギング技術を用いる攻撃からのアプリケーション又はライブラリのようなソフトウェアの保護に関する。

デバッギングは、コードのエラーを識別できるプロセスである。このための１つのツールは、デバッガ、多くのオペレーティングシステムによってデバッグされるコードと対になることができる一種のユーティリティである。例外または他のエラーが発生すると、これは、その場合はコードを検査して、この問題の起点を識別することが可能であるデバッガに報告される。

デバッガをコードと対にする能力は、そのコードのセキュリティを危うくするために悪意の人々により利用された。特に、デバッガがコードの動作を識別することが可能であるので、それは脆弱性のソースであり得る。

技術は、コードをこの種の攻撃から保護しようとするために開発された。これらの技術は、コードが作動中のデバッガがいつコードに不正に連結したかについて識別することを可能にする試みを含む。別の方法は、実行されるときにそれ自体デバッガを開始するようにコードを設計することである（このデバッガは「セルフデバッガ」と称される場合がある）。大部分のオペレーティングシステムは、単一のデバッガが所与のプロセスと対にされることを可能にするだけであり、セルフデバッガが、悪意のあるデバッガがさもなければ使用することを望むことができる空間を占有することを意味する。

従来のコードプロセス、並びに本開示のカップル・コード・プロセス及びデバッガプロセスの主要な機能の略図である。 実施形態による実行時ステップを示すフローチャートである。 本開示によるバイナリの生成の主要な態様を示す。 好ましい実施形態を実施するためのハードウェア基盤を示す。

大まかに言うと、コードの動作を保護する方法が提供される。本開示に従って、方法は、コードプロセスを開始すること、及びコードプロセスにアタッチされたデバッガプロセスを初期化することを含むことができる。コードプロセスの実行中に、コードプロセスの機能に極めて関連する動作は、デバッガプロセスの中で実行できる。その結果、デバッガプロセスは、コードプロセスの機能に影響を与えずに置き換えられるか又は損なわれることがありえない。コードプロセスは、従って、変更されたか悪意のあるデバッギング技術による検査から保護できる。

この文脈において、「極めて」は、デバッガプロセスで行われるそれらの動作によって生ずる出力がコードプロセスの残りの部分のための入力として役立つこと、及びその入力がそのコードプロセスの他の入力と仮定するとコードプロセスがその正しい出力を生成することを可能にするのに必要であることを意味すると理解できる。

本開示のいくつかの態様において、ソフトウェアを保護する方法が提供される。この方法は、ソフトウェアプロセスを開始すること、及びデバッガプロセスをソフトウェアプロセスにアタッチすることを含むことができる。デバッガプロセスが少なくとも一回呼び出されるように、コードプロセスは、その場合は実行できる。起動に応じて、１つ以上の機能は、デバッガプロセス中に実行することができて、これらの機能は、ソフトウェアプロセスと関連したデータに依存する出力を有する。出力が、ソフトウェアプロセスと関連したデータに依存して変化することがあり得る（即ちそれは予定されていない）ので、ソフトウェアプロセス及びデバッガプロセスの両方とも正しく作動するときに、全体の機能は達成されるだけである。これは、コードを分析するためにデバッガプロセスに対する干渉の余地を残さない。

この態様のソフトウェアプロセスが、デバッガによってデバッグされているプロセスに代わるので、それは、「デバッギ（ｄｅｂｕｇｇｅｅ）」プロセスと考えることができる。デバッガプロセスは、ソフトウェアプロセスが開始されるときか又は後の時間に初期化できる。例えば、特定の機能（例えばライブラリ）がソフトウェアプロセスにロードされるときに、デバッガプロセスは初期化できる。いくつかの実施例において、ソフトウェアプロセスは、デバッガプロセスを初期化するためにフォーク（ｆｏｒｋ）する。他の実施例において、デバッガプロセスは、最初に初期化されて、次に、ソフトウェアプロセスを生成するためにフォークすることができる。

いくつかの実施形態では、出力は、ソフトウェアプロセス用のデータ出力を含む。このように、デバッガプロセス内の機能の出力は、ソフトウェアプロセスの後の動作に直接影響することがありえて、それによって、ブレークするのが容易でない方法で２つのプロセスをきつく連結する。デバッガプロセスの機能の出力は、ソフトウェアプロセスのためのデータ入力を含み、前記データ入力は、ソフトウェアプロセスの実行のために重要である。

いくつかの実施形態では、所与の機能の出力は、継続的な実行のためにソフトウェアプロセス内で複数の戻り点を示すことができる。このように、少なくとも１つの機能のための戻り点は、（固定されるよりはむしろ）可変的である。制御フローは、従って、デバッガプロセスの動作に従って可変的であり、そして容易に推定されるかまたは再作成されることができない。

いくつかの実施形態では、デバッガプロセス・デバッガプロセスは、１つ以上の機能がソフトウェアプロセスのアドレス空間の中のメモリからデータを検索することを可能にするメモリサポート機能を提供する。このように、プログラム関連の機能が、あたかもソフトウェアプロセスの中で実行されるかのように、それらは、データを処理する能力を有することができる。

コードプロセス中のブレークポイントに達すると、デバッガプロセスを呼び出すことができる。ソフトウェアプロセスが終了すると、デバッガプロセスは、ソフトウェアプロセスから切り離すことができる。ソフトウェアプロセスが完了したか又はその他の理由（例えば強制終了されるとき）で、それは終了できる。或いは、ソフトウェアプロセス中の機能が、プロセスが全体として終了するのを待つよりはむしろ終了すると、デバッガプロセスは、ソフトウェアプロセスから切り離すことができる。

いくつかの実施形態では、ソフトウェアプロセスは、プログラムとして実行可能なファイル、例えばアプリケーションを実施する。他の実施形態では、コードプロセスはライブラリを実施する。

本開示の別の態様において、保護されるコードを生成する方法が提供される。デバッガに移行されるオブジェクトコード内のコードフラグメントを識別できる。バイナリコードは、次に、生成することができて、そこでは、実行時のバイナリコードによって、デバッガプロセスがソフトウェアプロセスにアタッチし、識別されたコードフラグメントは、デバッガプロセス中に実行される。ソフトウェアプロセス及びデバッガプロセスは、単一プロセスからフォークすることができる。例えば、ソフトウェアプロセスは、デバッガプロセスを初期化できる。

生成するステップは、バイナリコード内に一般的なデバッガ機能に対応する所定のコードを組み込むことを含むことができる。生成ステップは、デバッガのいくつかの所定の態様を組み込むリンキングステップであり得る。この種の態様は「ミニデバッガ」と称する場合がある。このように、全体のデバッガは、いくつかの一般的な態様並びに識別されたコードフラグメントの包含によって、ソースコードに特有のいくつかの態様を含む。

この方法は、ソースコードからデバッガに移行されるコードフラグメントを識別する１つ以上の注釈を抽出することを含むことができる。ソースコードは、次に、オブジェクトコードを生成するためにコンパイルされる。バイナリコードは、次に、オブジェクトコードから生成されて、識別されたコードフラグメントは、バイナリコードのデバッガと統合できる。このようにして、バイナリコードの生成は、識別されたフラグメントを別の位置の方へ動かすために再書込みの要素を含むリンキングステップであり得る。バイナリコードが、次に使われるときに、ソースコードの機能に関連できる、最初のソースコードの態様を含むデバッガが生成される。

いくつかの実施形態において、バイナリコードは、ソースコードに対応するが識別されたコードフラグメントを除外する第１のバイナリコードファイル、及びデバッガに対応する第２のバイナリコードファイルを含む。或いは、単一のバイナリコードファイルは、ソースコード及びデバッガの両方を組み込むことができる。

本開示の更なる態様は、上記の態様の方法を実行するためにコンピュータ実行可能な命令を含むコンピュータ実行可能なプログラム製品に関する。本開示の態様は、上記の態様の方法を実行するように構成される装置にも関することができる。

いくつかの特定の実施形態は、ここで同じ参照符号が同じ特徴を指す添付図面を参照して実例によって説明される。

バイナリ書換え技術によって、本開示は、機能の全部のチャンクを最初のソフトウェアからセルフデバッガへ移行できる。これは、いくつかの利点を提供する。第一に、セルフデバッガの入出力動作は、もはや予め決められず、セルフデバッガが介入するたびに、それは予め決められないが、保護プログラムの機能が変化できるほどその代わりに変化できる異なる機能を実行する。これは、保護をオートメーション化した分析、難読化の解除、及びデコンストラクションに対してずっと強じんにする。第二に、攻撃者が、最初のプログラムに相当する制御フロー及びデータフローを見つけ出すことができる場合であっても、攻撃者が保護を取り消して、その最初のプログラムを再構成することは、非常により難しくなる。組み合わせて、これらの２つの長所は、追跡されるか又はライブでデバッグされる機能プログラムを維持すると共に、攻撃者がセルフデバッガを切り離すことを非常により難しくする。

全体のセルフデバッガ設計
図１は、本開示によるセルフデバッギング方式の基本的概念を示す。この実施形態は、Ｌｉｎｕｘ（登録商標）（及びアンドロイド（登録商標）のような派生品）を目標とし、原理は、他の環境、例えばＷｉｎｄｏｗｓ（登録商標）及びＯＳ Ｘに適用することもできる。

図１の左側に、小さい制御フロー・グラフ・フラグメントを含む、最初の保護されないアプリケーションが示される。示されたアセンブリコードは、（疑似）ＡＲＭｖ７コードである。この保護されないアプリケーションは、２つの部分、即ち、図の中央に示すように大部分は最初のアプリケーションに対応するデバッギ、及び右側に示すようにデバッガから成る保護されたアプリケーションに変換される。デバッギ及びデバッガに注入されるいくつかの新しい構成要素は別として、最初のアプリケーションとの主要な差は、制御フロー・グラフ・フラグメントがアプリケーションからデバッガに移行されたことである。この特定の実施形態は、機能呼び出しのような手順間制御フローを含まない全ての単一エントリ、複数の終了コードフラグメントをサポートする。

この種のフラグメントの移行は、単純な複写を超えたものであり、保護されたアプリケーションにおいては、デバッガアドレス空間で実行する移行されたコードが、デバッギアドレス空間にまだあるデータに好ましくはアクセスできるので、ＬＤＲ命令のようなメモリ参照は、変形しなければならない。全ての関連した構成要素および変形は、後の節において更に詳細に述べられる。

移行されたフラグメントは、アプリケーションの動作にとって好ましくは重要である。即ち、デバッガプロセスに移行されるそれらの動作により生成される出力は、コードプロセスの残りの部分のための入力として役に立ち、そしてその入力は、コードプロセスがそのコードプロセスの他の入力ならばその正しい出力を生成することを可能にするために必要である。この要件は、実際には見落としやすい。例えば、典型的プログラマーは、デバッガの前後関係においてコードプロセスの変数の初期化を実行することを考えるかもしれない。しかしながら、一般に、デバッガプロセスにおいてコードプロセスから変数の初期化を実行することは十分でない。その理由は、次のことにある。実際には、プロセスにおいて、（例えば、機能への入力時の局所変数の）変数初期化が、プロセスの正しい機能のために、そして正しい出力を生成するために実際に必要されずに、良好なプログラム実行の結果として、そしてソースプログラミング言語定義要件を満たすために実行されることがたいへん頻繁に起こる。これは、変数がコードプロセスの実行された経路において、単に使われないという理由か、又はそれらがコードプロセスの実行又は出力に影響を与えることができる前に、初期値が重ね書きされるという理由であり得る。

実行時に、この保護されたアプリケーションの動作は、以下の通りである。最初に、あたかもデバッギが原アプリケーションであるかのように、それは、ステップｓ２１で開始する。新しく注入された初期化子は、次に、デバッガのための新しいプロセスからフォークし、そこにおいて、デバッガの初期化子は、デバッギプロセスに直ちにアタッチする。このように、デバッガプロセスは開始されて、ステップｓ２２でデバッギプロセスにアタッチされる。

後でプログラムの実行の間に、移行されたコードフラグメントのエントリポイントに達すると、アプリケーションの１つの可能な制御フローは、図１の矢印をたどる。アプリケーション／デバッギにおいて、命令を誘導する例外が実行されて、ステップｓ２３で例外が生じる（図１に１と表示されている）。デバッガは、この例外を通知されて、ステップｓ２４でそのデバッガループでそれを処理する（図１に２と表示されている）。特に、このループのコードは、デバッギからプロセス状態を取り出して対応する移行されたコードフラグメントを調べて、ステップｓ２５で制御をそのフラグメントのエントリポイントへ移す役割を果たす（図１に３と表示されている）。前述のように、そのフラグメントにおいて、メモリアクセスはそのままで実行することができない。それで、それらは、ステップs26でデバッギのアドレス空間のメモリにアクセスするメモリサポート機能５の起動４と置き換えられる。移行されたコードフラグメントにおいて、出口点６に最終的に達すると、制御は、ステップｓ２７でデバッガループ７の対応点へ移されて、それは、ステップｓ２８でデバッガで計算されるデータによってデバッギの状態を更新し、８制御は、ステップｓ２９でデバッギへ戻される。複数の出口を有するコードフラグメント、例えば図の実施例の場合は、制御は、デバッギの複数の継続点へ戻すことができる。この点に関しては、本開示のデバッガは、既存のセルフデバッガより複雑な方法で機能し、それは、デバッギとデバッガの間で前後の制御フロー転送の間に１対１のマッピングを実施する。

最終的に、アプリケーションが終了すると、埋込み型終了化子は必要な分離動作を実行する。

この方式が、プログラムとして実行可能なファイル（即ち、主要な機能及びエントリポイントを有するバイナリ）を保護するためだけでなく、共有ライブラリを保護するためにも展開できる点に留意することは重要である。プログラムとして実行可能形なファイルのように、ライブラリは、それらがＯＳローダーによってロードされるか又はアンロードされるときに実行される初期化子及び終了化子を含むことができる。その時、必要なフォーキング、アタッチング、及び分離は、同様に実行できる。

以下の説明が、アプリケーションを保護することに主に関連するが、暗に、教示はアプリケーション及びライブラリを等しく適用する。ライブラリに特に関連する１つの態様は、デバッガの適当な初期化及び終了化の必要である。ライブラリが、プログラムの単一の実行中に複数回ロードされるか又はアンロードされることがまれでないので、これは必要である。例えば、反復してロードしてアンロードすることは、メディアプレーヤ及びブラウザのプラグインにとってしばしば起こる。更に、主プログラムが、それらがそれ自体開始されるときに１つのスレッドだけから成るのに対して、それらは、ライブラリがロードされてアンロードされるときは複数のスレッドから成ることができる。

ツールサポート
図３は、１つの可能な概念上のツールフローを示す。

ソースコード注釈
デバッガに移行されるコードフラグメントを決定するために、多くのオプションが存在する。図に示す１つ、そして又我々が我々の実施態様で用いるものは、プラグマ、コメント、又はデバッガプロセスに移行されるコード領域の始め及び終了をマークするその他の形態の注釈によって、ステップｓ３１でソースコードに注釈をつけることである。単純なグレップ（ｇｒｅｐ）は、注釈及びそれらの行番号を抽出して、ステップｓ３２でその情報を注釈ファイルに格納するのに十分である。

代わりのオプションは、保護される手順又はソース・コード・ファイルをリストすることか、或いは興味のあるフラグメントを半自動式に選択するためにトレース又はプロフィールを集めることである。

その点で、デバッガに移行されるフラグメントが、必ずしもまったくのホットフラグメントでなければならないというわけではない点に留意することは、重要である。デバッギとデバッガの間に強いアタッチメントを達成するために、比較的高い頻度で例外を提起することが十分であるが、これは最もホットなコードパスにある必要はない。フラグメントの選択のための更なる考慮点は、以下に詳述される。あらゆる提起された例外が、大きな量のオーバーヘッド（コンテキストスイッチ、多くのｐｔｒａｃｅコール、...）を導入するので、保護のレベルを損なわずにそれらの数を最小化することが重要である。

標準コンパイラ及びツール
開示されたセルフデバッギング方法を展開するために、いかなる「標準」コンパイラも、ステップｓ３３で用いることができる。技術は、いかなる規制もコンパイラによって生成するコードに課さない。実験評価において、ＧＣＣ及びＬＬＶＭの両方が使われ、そこにおいてコード生成に適応するか又は調整する必要がなかった。

１つの必要条件は、しかしながら、コンパイラ及びバイナリのユーティリティ（アセンブラ及びリンカー）がリンクタイムリライタに十分に正確なシンボル及び再配置情報を提供するということである。これは、信頼性が高い保守的なリンクタイムコード分析及び変換が、選択されたコードフラグメントの移行及び変換を含む全部のセルフデバッギング方式を実施することを可能にするために必要とされる。十分に正確な情報を提供することは、一般的に用いられるツールのために確実に手の届く範囲内にある。ＡＲＭ所有のコンパイラは、例えば、デフォルトによって長期間そうした。そしてＧＮＵ ｂｉｎｕｔｉｌｉｓ、ＧＣＣ、及びＬＬＶＭの場合は、非常に単純なパッチは、それらのツールがあまりに積極的シンボル緩和及び再配置簡略化を実行するのを防止して、マッピングシンボルを挿入してコードでデータをマークすることをそれらに強いるために十分である。これらの要件は、以前に文書化されて、それらは、手動で書込みされたアセンブリコードで満ちている、Ｌｉｎｕｘ（登録商標）カーネル及びＣライブラリのＣＩＳＣ（ｘ８６）及びＲＩＳＣ（ＡＲＭｖ７）版の両方と同程度の複雑且つ非慣習的なコードの信頼性が高い保守的なリンクタイム書換えを実行するために十分であることが示された。

デバッガの大きい共通部分「ミニデバッガ」は、標準コンパイラとプレコンパイルして、次に、保護されるアプリケーションに簡単にリンクした。他の部分、例えば、移行されたフラグメントの各々のためのデバッグループのプロローグ及びエピローグは、それらが特定のフラグメントのためにカスタマイズされるときに、リンクタイムリライタによって生成される。

リンクタイムリライタが、ソースコードにおいて注釈付きフラグメントを識別することを可能にするために、それは、それにソースコードファイルから抽出された行番号情報を渡して、コンパイラに、デバック情報付きのオブジェクトファイルを生成させるのに十分である。そのデバック情報は、次に、バイナリコードのすべてのアドレスを、リライターが注釈から行番号にリンクすることができるソース行番号にマップする。

バイナリ、ライブラリ、及びプロセス
リンクタイムリライタは、ステップｓ３５で保護されたアプリケーションを生成するために２つのオプションを有する。第１のオプションは、２つのバイナリ、即ち、アプリケーション／デバッギのための１つ、及びデバッガのための１つを生成することである。セキュリティの観点から、これは好ましいかもしれない。その理由は、アプリケーション意味論及びその実施が、次に、複数のバイナリを通じて分散されて、それは、攻撃者が保護を取り消す、即ち、デバッギを最初のアプリケーションに戻すことをおそらく更により難しくするからである。しかしながら、デバッガの開始が、次に、第２のバイナリをロードすることも必要とするので、このオプションは、追加の実行時オーバーヘッドを導入する。

以下の更なる実施例において使用される代わりのオプションは、全てのデバッギコード及び全てのデバッガコードを１つのバイナリに埋め込むことである。その場合には、単純なフォーキングは、デバッガを開始するのに十分である。これがセルフデバッギングにより提供される保護に対する攻撃を容易にするか否か、及びその程度は、未解決な研究課題である。

実施態様
初期化及び終了処理
追加の初期化ルーチンを、保護されたバイナリに加えることができる。このルーチンは、バイナリがロードされるとすぐに呼び出される（それが高い優先権を割り当てたので）。その後に、バイナリのｉｎｉｔセクションにリストした全ての他のルーチンは実行される。

この初期化ルーチンはフォーク（）を呼び出し、それで親（ｐａｒｅｎｔ）および子供（ｃｈｉｌｄ）と呼ばれる２つのプロセスを生成する。一旦初期化ルーチンが終了すると、親プロセスは、通常は次の初期化ルーチンを呼び出すことによって実行を続ける。

２つのオプションは、デバッガ及びデバッギの役割を割り当てるために存在する。フォークの後に、子プロセスは親プロセスにアタッチするか、或いは逆も又同じである。前者の場合、子供はデバッガになり、そして親はデバッギになり、後者の場合、役割は明らかに逆転する。

前のオプションが好ましい。親プロセス（即ち、デバッギ）は、主要なアプリケーションプロセスのままであり、そしてそれは同じプロセスＩＤ（ＰＩＤ）を保つ。これは、最初のＰＩＤに依存する全ての外部アプリケーション及びプロセス間通信路の継続実行または利用を容易にする。その理由は、例えば、それらは保護されたライブラリのローディング及びフォーキングの前に準備されたことである。

しかしながら、この方式はそれ自体の課題を伴う。すでに述べたように、共有ライブラリは、プログラムの実行中はいつでも、（ｄｌｏｐｅｎ（）およびｄｌｃｌｏｓｅ（）を使用して）ロードしたり、アンロードしたりすることができる。それ故、最初にロードされてフォークされたデバッガが、その初期化をまだ完了しない間に、保護された共有ライブラリがアンロードされて再びロードされることができるという潜在的課題がある。これは、両方ともデバッギにアタッチすることを試みる（そして１つは失敗する）、２つのデバッガプロセスの同時の存在に結果としてなることがあり得る。この状況を回避するために、我々は、ｄｌｏｐｅｎ（）を呼び出したスレッドの実行をブロックする。それで、その時間までは、そのスレッドは、それがｄｌｏｐｅｎ（）によって得たハンドルを用いてｄｌｃｌｏｓｅ（）を呼び出すことができず、そしてそれは、ハンドルを別のスレッドにも渡すことができない。デバッギの初期化ルーチンの無限ループは、デバッガがその進行を許可する前に、ローディングスレッドが初期化ルーチンを出るのを防止する。

初期化ルーチンはまた、終了化子をデバッギにインストールする。この終了化子は多くのことをしない。プログラム出口で（又は共有ライブラリがアンロードされるときに）、それは、ＳＩＧＵＳＲ１信号を上げることによって、この事実をミニデバッガに単に知らせ、ミニデバッガを全てのデバッギのスレッドから分離させて、デバッガプロセスをシャットダウンさせる。

マルチスレッディングサポート
デバッガをアタッチすることは、特に保護された共有ライブラリの場合、簡単ではない。ライブラリがロードされるときに、アプリケーションは、いくつかのスレッドから成るかもしれない。それらのうちの１つだけは、ｄｌｏｐｅｎへのその呼び出しの間にデバッギ初期化ルーチンを実行する。１つのフォークだけが実行されるので、これは良好であるが、それは、１つのスレッドだけが前節に記載の無限ループに入るという不利な面をもたらす。デバッギプロセスの他のスレッドは、動作し続けて、デバッギ初期化ルーチン又はデバッガ初期化ルーチンの実行中のいかなる時点でも新規なスレッドを生成するかもしれない。適当な保護を確実にするために、デバッガは、その初期化の一部としてデバッギプロセスのあらゆるスレッドにアタッチしなければならない。デバッガがその間にデバッギにおいて生成されるいかなるスレッドも見逃さないことを確実にするために、我々は、プロセスのスレッドごとにエントリを含む、／ｐｒｏｃ／［ｐｉｄ］／タスクディレクトリを使用する。デバッガプロセスは、このディレクトリのエントリを繰り返すことによって、そして新しいエントリが見つからないまで繰り返し続けることによって、全てのスレッドにアタッチする。ＰＴＲＡＣＥ＿ＡＴＴＡＣＨ要求によって生じるスレッドにアタッチすると、スレッドも止められる（そしてデバッガは、ＯＳによってこのイベントを通知される）。そして、それがその時以来新規なスレッドをもはや生じることができないことを意味する。それで、有限数のスレッドを生じるいかなるプログラムに対しても、全てのスレッドにアタッチする反復手順は、終了すると保証される。一旦全てのスレッドがアタッチされると、デバッギの無限ループは終わり、そしてその止められたスレッドは続くことができる。追加スレッドが、プログラム実行中に後で生成されると、デバッガは、ＯＳによってそれらに自動的にアタッチされて、全ての必要なブックキーピングが実行されることができるように、それは信号を得る。

制御フロー
制御フローを移行されたコードフラグメントに変形することは、いくつかの部分から成る。我々は、デバッガに通知するために例外を提起することを検討し、ＩＤの転送は、デバッガにどんなフラグメントが実行されることになっているか、及びコードフラグメントごとに加えられるカスタマイズされたプロエピローグとエピローグを通知する。

例外の提起
デバッガの実際の通知は、例外を提起させるいかなる命令によっても起こることがあり得る。我々の実施態様において、我々は、簡単にするためにソフトウェアブレークポイント（即ち、ＡＲＭｖ７に関するＢＫＰＴ命令）を使用する。他のより顕著でない例外、例えば、違法であるか未確定の命令によって生じるそれらは、もちろん使用できる。この種の命令が、直接的な制御フロー（直接的な分岐又はフォールスルーパス）を経て届くとき、それらは、もちろん、静的に容易に検出できる。しかし、間接的な制御フロー転送がコードセクションのデータへジャンプするために用いられて、データビットが違法であるか未確定の命令に対応するとき、静的検出は非常により難しくなることがあり得る。同様に、それらのオペランドが「無効な」場合にだけ例外を投げる法的命令は、命令の目的を隠すために用いることができる。この種の命令は、ゼロ除算、無効なメモリアクセス（即ち、セグメンテーションフォールト）、又は無効なポインタ（バスエラーに結果としてなる）のデリファレンスを含む。

ＩＤの転送
それがあるコードフラグメントを実行することをデバッガに基本的に求めているので、我々は、例外を提起するデバッギのスレッドを要求スレッドと称する。

デバッガは、ＯＳによって要求について通知された後に、どのフラグメントを実行するべきか理解する必要がある。これを可能にするために、デバッギは、フラグメントのＩＤを多くの方法で渡すことができる。１つのオプションは、ＩＤとして命令を誘導する例外のアドレスを単に使用することである。別のオプションは、例外を提起する直前に固定レジスタに、又は固定記憶場所にそれを配置することによってＩＤを渡すことである。我々の実施態様において、我々は後のオプションを使用した。デバッギの複数のスレッドが、異なるフラグメントを並行して要求できるので、記憶場所は汎用位置ではありえない。その代わりに、それはスレッドローカルであることを必要とする。各スレッドがそれ自体のスタックを有するので、我々は、要求スレッドのスタックのトップを介してフラグメントのＩＤを渡すことを選択した。

例外を提起するために用いる命令のタイプに応じて、他の方法を同様に構想できる。例えば、除算（ゼロによる）命令の除数オペランドは、同様にＩＤを渡すために用いることができる。

プロローグ及びエピローグ
ミニデバッガのデバッガループは、フラグメントが実行される前にデバッギのプログラム状態を取り出し、そしてその実行の後にそれをもとに戻す。標準ｐｔｒａｃｅ機能は、こうするために用いる。

移行されたコードフラグメントごとに、デバッグループは、コードフラグメントの前後それぞれで実行されるカスタムのプロローグ及びエピローグも含む。プロローグは、必要な値を構造体からレジスタにロードし、エピローグは、必要な値を書込んで構造体に戻す。プロローグは、それがフラグメント（いわゆるライブインレジスタ）において実際に用いられるレジスタにロードするだけであるという点でカスタマイズされる。エピローグは、ライブアウトであり（即ち、デバッギにおいて消費される）、そしてコードフラグメントに上書きされた値を格納するだけである。

メモリアクセス
移行されたコードフラグメントのロード又は格納動作ごとに、デバッギのメモリへのアクセスが必要である。この種のアクセスを実行する複数のオプションが存在する。第１は、ｐｔｒａｃｅ機能を単に使用することであり、デバッガは、デバッギのアドレス空間において読込み及び書込みを行うために、ＰＴＲＡＣＥ＿ＰＥＥＫＤＡＴＡ及びＰＴＲＡＣＥ＿ＰＯＫＥＤＡＴＡ要求を実施できる。この場合に、読込み又は書込みが行われる語当たり、ｐｔｒａｃｅシステムコールが必要であり、それは著しいオーバーヘッドに結果としてなる。いくつかの最近のＬｉｎｕｘ（登録商標）版は、より広いアクセスをサポートするが、それらは、Ａｎｄｒｏｉｄ（登録商標）のように、まだ至る所で利用できるわけではない。

第２のオプションは、デバッガにおいてデバッギの／ｐｒｏｃ／［ｐｉｄ］／ｍｅｍファイルを開き、次に、このファイルに単に読込み又は書込みを行うことである。これは実施するのがより容易であり、そしてより広いデータは、単一のシステムコールによって読込み又は書込みを行うことができるので、しばしば、この方法はより急速である。別のプロセスの／ｐｒｏｃ／［ｐｉｄ］／ｍｅｍへの書込みは、Ｌｉｎｕｘ（登録商標）／Ａｎｄｒｏｉｄ（登録商標）カーネルの全ての版でサポートされているわけではなく、しかしながら、それで我々のプロトタイプでは、書込み要求は依然として第１のオプションによって実施される。

第３のオプションは、第２のものに基づいている。バイナリリライターが、どのメモリページが移行されたコードフラグメントでアクセスするかについて決定できる場合、デバッグループは、オプション２を使用してそれらのページをデバッガアドレス空間に実際に複製できる。デバッガのフラグメントは、次に、複製されたページにアクセスするために、正規のロード及び格納動作を単に実行し、そしてフラグメントが実行した後に、更新されたページは、複製されてデバッギへ戻される。例えば、コードフラグメントが、スタックのバッファにアクセスするためにループを含む場合、このオプションはより急速であり得る。我々が第３のオプションを前の２つのオプションと比較するために行った実験で、この技術がわずか８つのメモリアクセスのために価値があるかもしれないことが分かった。しかしながら、我々は、我々のプロトタイプにおいてそれに対する確実なサポートを実施しなかった。どのページがコードフラグメントによってアクセスされるか決定するための保守的なリンクタイム分析は、この点で将来の仕事のままである。

全ての割当られたメモリ（又は少なくともヒープ）が、デバッギとデバッガプロセス間の共有メモリとして割り当てられるように、第４の潜在的オプションは、例えば、カスタムヒープメモリ管理ライブラリ（ｍａｌｌｏｃ，ｆｒｅｅ，…）を提供することによって、デバッギに適応することである。次に、デバッガのコードフラグメントは、データに直接アクセスすることができる。勿論、フラグメントは、２つのアドレス空間の間でのアドレスの変換を含むために、依然として書き換えることを必要とするが、おそらく、このオプションのオーバーヘッドは、他のオプションのオーバーヘッドより非常に小さいことがあり得る。このオプションを実施してそれを評価することは、この点で将来の仕事のままである。

セキュリティの点で、いろいろなオプションは、それらが、攻撃者がプログラムの最初のセマンテイクスをリバースエンジニアリングして、セルフデバッギング版を最初のプログラム相当品に分解することが難しくなるように影響を与えるという点で、おそらく異なる影響も有する。

セルフデバッギングの他の保護との組み合わせ
ＭＡＴＥ攻撃に対する強力なソフトウェア保護を提供するために、追加の保護技術を使用できる。例えば、セルフデバッギングに加えて、静的解析を防止する難読化は、あらゆる種類の攻撃を防止するために不正加工防止技術と共に使用できる。

例えば、セルフデバッギング方法を実施するバイナリリライターは、また、多くの他の保護、例えば、以下の１つ以上を適用できる。
制御フロー難読化：不明確な述部の周知の難読化、制御フローフラット化、及び 分岐機能、
コード・レイアウト・ランダム化：コードレイアウトの間、全ての機能からのコ ードは混ぜられて、レイアウトはランダム化される、
コード可動性：コードフラグメントが静的バイナリから取外されて、いわゆるモ バイルコードとして、実行時のアプリケーションにダウンロードされるだけで ある技術、
コードガード：ハッシュがプロセスのコードにわたって計算される技術のオンラ イン及びオフラインの実施は、コードが変えられなかったことを検査するため に空間をアドレス指定する、
制御フロー完全性：復帰アドレスが内部機能が外部コードから呼び出されること を防止するために検査される軽量技術、
命令セット仮想化：固有コードがネイティブに実行される代わりに埋め込みバー チャルマシンにより解釈されるバイトコードに翻訳される技術。

セルフデバッギング技術をそれらの保護の全てと組み合わせることは、実際にはいかなる課題も提起しない。リンク時間リライターにおいて、保護の全てに対して全ての変換を実行するために、そしてそれらの技術が実際に構成しないときに複数の技術が同じコードフラグメントに適用されることを防止するために良好な命令を決定することは困難ではない。例えば、モバイルコードは、ランダム化された位置へ再配置される。全ての保護を処理することは、なんらかのブックキーピングを間違いなく必要とするが、複雑なことは何もない。

実行時動作に関しては、技術は同様に構成する。複数の技術は、初期化子及び終了化子を必要とするが、デバッガプロセスにおいて、そのデバッガプロセスがデバッガであり、そしてコード可動性又はその他の技術のための別のクライアントであってはならないだけであるので、我々は他の保護の初期化子を実行することを望まない。他の初期化子が実行するのを防止するために、セルフデバッガ初期化子は、最高優先度を与えられる。バイナリ又はライブラリがロードされるときに、それらは最初に実行され、そしてデバッガ初期化ルーチンは、実初期化子並びにデバッグループの両方とも実際に実施する。ルーチンは、従って、決して終わらない（即ち、終了化子が呼び出されない限り）、そして、それ故、制御は、バイナリに存在するかもしれない他の初期化子へ決して転送されない。

評価
評価プラットフォーム
セルフデバッガの１つの実施態様は、ＡＲＭｖ７プラットフォームを目標とする。具体的に、この実施態様は、Ｌｉｎｕｘ（登録商標）３．１５及び（ルート化を解除された）Ａｎｄｒｏｉｄ（登録商標）４．３＋４．４の実施を目標として、広範囲に評価した。技術がＬｉｎｕｘ（登録商標）（４．７）及びＡｎｄｒｏｉｄ（登録商標）（７．０）の最新版でまだ機能し、そしてそれは実際このケースであることが更に確認された。

テストハードウェアは、いくつかのデベロッパーボードから構成された。Ｌｉｎｕｘ（登録商標）の場合は、シングルコアのテキサスインスツルメンツＯＭＡＰ４プロセッサを特徴とするＰａｎｄａ Ｂｏａｒｄ、ダブルコアのＳａｍｓｕｎｇ Ｅｘｙｎｏｓプロセッサを特徴とするＡｒｎｄａｌｅ Ｂｏａｒｄ、及びシングルコアのＦｒｅｅｓｃａｌｅ ｉ．ＭＸ６ｑプロセッサを特徴とするＢｏｕｎｄａｒｙ Ｄｅｖｉｃｅｓ Ｎｉｔｒｏｇｅｎ６Ｘ／ＳＡＢＲＥ Ｌｉｔｅ Ｂｏａｒｄが使われた。後のボードは、Ａｎｄｒｏｉｄ（登録商標）版にも用いられた。

ツールチェーンにおいて、ＧＣＣ ４．８、ＬＬＶＭ ３．４及びＧＮＵ ｂｉｎｕｔｉｌｓ ２．２３が用いられた。コードは、以下のフラグによってコンパイルされた：−Ｏｓ−ｍａｒｃｈ＝ａｒｍｖ７−ａ−ｍａｒｍ−ｍｆｌｏａｔ−ａｂｉ＝ｓｏｆｔｆｐ−ｍｆｐｕ＝ｎｅｏｎ−ｍｓｏｆｔ−ｆｌｏａｔ。

使用事例
セルフデバッギング方式は、複数の使用事例において機能することを示した。例えば、デジタル権利管理シナリオにおいて、以下の実際的な考慮点がみられた。

この使用事例は、Ａｎｄｒｏｉｄ（登録商標）メディアフレームワーク及びＡｎｄｒｏｉｄ（登録商標）ＤＲＭフレームワークのために、Ｃ及びＣ＋＋で書かれる、２つのプラグインから構成された。これらのライブラリは、暗号化された動画にアクセスして、それらを解読するために必要である。Ｊａｖａ（登録商標）でプログラムされるビデオアプリは、ビデオにアクセスするＧＵＩとして用いられる。このアプリは、Ａｎｄｒｏｉｄ（登録商標）のメディアサーバー及びＤＲＭフレームワークと通信して、フレームワークにそれがプラグインを必要とするベンダーを知らせる。要求に応じて、これらのフレームワークは、次に、プラグインをロードする。具体的に、これらのサーバーは、Ａｎｄｒｏｉｄ（登録商標）で動作するメディアサーバー及びｄｒｍｓｅｒｖｅｒプロセスである。

実験および開発の間に、この使用事例をこの技術のための完全なストレステストにするいくつかの特徴が観察された。第１に、メディアサーバーは、マルチスレッド化されて、常に新規なスレッドを生成して、キルする。第２に、プラグインライブラリは、ロードされて、しばしばアンロードされる。時々、ライブラリの初期化が終わる前でも、アンローディングは開始される。第３に、プロセスがクラッシュするとすぐに、新規な例は開始する。時々、これによって、Ｊａｖａ（登録商標）ビデオプレーヤが中断されない機能を続けることができて、時々、それはそうしない。これは、我々の技術の実施をデバッグすることをそれがすでに単純なアプリケーション用であるより更に複雑にする。第４に、メディアサーバー及びｄｒｍｓｅｒｖｅｒは、頻繁なプロセス間通信に関係している。にもかかわらず、成功した実施態様は、上記の原則に基づいて達成された。

技術は、多くの他の使用事例シナリオに適用できる。例えば、セキュリティが望ましいその他のシナリオのモバイルバンキングにおいても。図４は、コンピュータに本願明細書で述べる技法のいかなる１つ以上も実行させるために、一組の命令を実行できるコンピュータ４００の１つの実施態様のブロック図を示す。代替の実施態様において、コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）、イントラネット、エクストラネット、又はインターネットにおいて、他の機械に接続する（例えば、ネットワーク化する）ことができる。コンピュータは、クライアント・サーバー・ネットワーク環境のサーバー又はクライアントマシンの能力で、或いはピア・ツー・ピア（又は分散される）ネットワーク環境のピアマシンとして作動できる。コンピュータは、パーソナルコンピュータ（ＰＣ）、タブレット型コンピュータ、セットトップボックス（ＳＴＢ）、パーソナル携帯情報機器（ＰＤＡ）、移動電話、ウェブ機器、サーバー、ネットワークルーター、スイッチ又はブリッジ、或いはその機械によって、とられる措置を特定する一組の命令（経時的又はその他）を実行できるいかなる機械でもあり得る。更に、単一のコンピュータだけが例示されるが、用語「コンピュータ」は、本願明細書において述べる技法のいかなる１つ以上も実行するために一組（又は複数の組）の命令を個々に、又は共同で実行する機械（例えば、コンピュータ）のいかなるコレクションも含むとも受け取られる。

例示のコンピュータ４００は、処理装置４０２、主メモリ４０４（例えば、読出し専用メモリ（ＲＯＭ）、フラッシュメモリ、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、例えば、同期型ＤＲＡＭ（ＳＤＲＡＭ）又はラムバスＤＲＡＭ（ＲＤＲＡＭ等））、スタティックメモリ４０６（例えば、フラッシュメモリ、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）等）、及び二次メモリ（例えば、データ記憶装置４１８）を含み、それらはバス４３０を介して互いに通信する。

処理装置４０２は、１つ以上の汎用プロセッサ、例えば、マイクロプロセッサ、中央演算処理装置等を表す。より詳しくは、処理装置４０２は、複合命令セット演算（ＣＩＳＣ）マイクロプロセッサ、減少した命令セツト演算（ＲＩＳＣ）マイクロプロセッサ、非常に長い命令ワード（ＶＬＩＷ）マイクロプロセッサ、他の命令セットを実施するプロセッサ、又は命令セットの組合せを実施するプロセッサであり得る。処理装置４０２は、１つ以上の特殊目的の処理装置、例えば、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ等でもあり得る。処理装置４０２は、本願明細書に述べる動作及びステップを実行するための処理ロジック（命令４２２）を実行するように構成される。

コンピュータ４００は、ネットワークインタフェース装置４０８を更に含むことができる。コンピュータ４００は、ビデオ・ディスプレイ・ユニット４１０（例えば、液晶ディスプレイ、ＬＣＤ）又は陰極線管、ＣＲＴ、英数字入力装置４１２（例えば、キーボード又はタッチスクリーン）、カーソル制御装置４１４（例えば、マウス又はタッチスクリーン）、及び音声装置４１６（例えば、スピーカ）も含むことができる。

データ記憶装置４１８は、本願明細書に記載の技法又は機能のいかなる１つ以上も実施する１つ以上の組の命令４２２が格納される１つ以上の機械可読記憶媒体（又はより詳しくは１つ以上の非一時的コンピュータ可読記憶媒体）４２８を含むことができる。命令４２２は、コンピュータシステム４００、主メモリ４０４、及びコンピュータ可読記憶媒体も構成する処理装置４０２によるその実行の間に主メモリ４０４内に、及び／又は処理装置４０２内に完全に又は少なくとも部分的にあることもできる。

上記の各種の方法は、コンピュータプログラムによって実施できる。コンピュータプログラムは、コンピュータに上記の各種の方法の１つ以上の機能を実行するように命令するように調整されるコンピュータコードを含むことができる。この種の方法を実行するためのコンピュータプログラム及び／又はコードは、１つ以上のコンピュータ可読媒体又は、更に一般的にいえば、コンピュータプログラム製品に関して、装置、例えばコンピュータに提供されることができる。コンピュータ可読媒体は、一過性又は非一過性であり得る。１つ以上のコンピュータ可読媒体は、例えば、データ伝送のための、例えばインターネットを通じてコードをダウンロードするための電子的、磁気的、光学的、電磁気的、赤外線、又は半導体のシステム、或いは伝播媒体であり得る。或いは、１つ以上のコンピュータ可読媒体は、１つ以上の物理的なコンピュータ可読媒体、例えば、半導体又は固体メモリ、磁気テープ、着脱可能なコンピュータディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、固定磁気ディスク、及び光ディスク、例えばＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ又はＤＶＤという形をとることができる。

実施態様において、本願明細書に記載のモジュール、構成要素、及び他の特徴（例えば、図４に関する制御ユニット４１０）は、個別の構成要素として実施されるか、或いは、ハードウェア構成要素、例えばＡＳＩＣＳ、ＦＰＧＡ、ＤＳＰ、又は個別化サーバーの一部としての同様の装置の機能において集積化される。

「ハードウェア構成要素」は、特定の動作を実行できる有形の（例えば、非一過性の）物理的な構成要素（例えば、一組の１つ以上のプロセッサ）であり、そして特定の物理的な方法で構成するか又は配置することができる。ハードウェア構成要素は、特定の動作を実行するように永続的に構成される専用の回路又はロジックを含むことができる。ハードウェア構成要素は、特殊目的のプロセッサ、例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）又はＡＳＩＣであるか、或いはそれを含むことができる。ハードウェア構成要素は、特定の動作を実行するためにソフトウェアによって一時的に構成されるプログラム可能なロジック又は回路を含むこともできる。

従って、「ハードウェア構成要素」というフレーズは、特定の方法で動作するために、又は本願明細書に記載の特定の動作を実行するために、物理的に構成されるか、永続的に構成される（例えば、物理的に組み込まれる）か、又は一時的に構成される（例えば、プログラムされる）ことができる有形の実体を含むと理解しなければならない。

加えて、モジュール及び構成要素は、ハードウェア装置内でファームウェア又は機能回路として実施できる。更に、モジュール及び構成要素は、ハードウェア装置とソフトウェア構成要素のいかなる組合せでも、又は、ソフトウェア（例えば、機械可読媒体又は伝送媒体に格納されるかさもなければ組み入れられるコード）だけで実施できる。

特に述べられない限り、以下の説明から明らかな様に、説明の全体にわたって、「受け取る」、「決定する」、「比較する」、「可能にする」、「維持する」、「識別する」、「置き換える」等のような用語を用いる説明は、コンピュータシステムのレジスタ及びメモリの中の物理的（電子的）量として表わされるデータを操作して、コンピュータシステムのメモリ又はレジスタ、或いは他のこの種の情報記憶、伝送、又は表示装置の中の物理的量として同様に表わされる他のデータに変換するコンピュータシステム又は類似の電子コンピュータの動作及びプロセスに関連すると認められる。

前記説明が例証を示すものであり、限定的ではないことを目的とすることを理解すべきである。多くの他の実施態様は、前記説明を読んで理解すると、即座に当業者にとって明らかである。本開示が特定の実施態様に関して説明されたけれども、本開示は、記載された実施態様に限定されなくて、添付の請求項の精神及び範囲内の変更態様及び改変で実践可能であると認識される。従って、本明細書及び図面は、限定的な意味よりもむしろ例示的な意味で考えるべきである。本開示の範囲は、従って、この種の請求項が有する等価物の完全な範囲とともに、添付の請求の範囲に関して決定しなければならない。

Claims (15)

1. ソフトウェアを保護する方法であって、
   ソフトウェアプロセスを開始するステップと、
   デバッガプロセスを前記ソフトウェアプロセスにアタッチするステップと、
   前記デバッガプロセスが少なくとも１回呼び出されるように、前記ソフトウェアプロセスを実行するステップと、
   前記デバッガプロセスの起動に応答して前記デバッガプロセス中に１つ以上の機能を実行するステップであって、前記１つ以上の機能は前記ソフトウェアプロセスと関連したデータに依存する出力を有するステップと、
   を含む方法。
2. 前記出力は、前記ソフトウェアプロセス用のデータ出力を含む請求項１に記載の方法。
3. 所与の機能の前記出力は、継続的な実行のために前記ソフトウェアプロセス中に複数の戻り点を示すことができる請求項１又は２に記載の方法。
4. 前記デバッガプロセスは、前記１つ以上の機能がデータを前記ソフトウェアプロセスのアドレス空間の中のメモリから検索することを可能にするためにメモリサポート機能を提供する請求項１〜３のいずれか１項に記載の方法。
5. 前記ソフトウェアプロセス中のブレークポイントに達すると、前記デバッガプロセスは呼び出される請求項１〜４のいずれか１項に記載の方法。
6. 前記ソフトウェアプロセスが終了すると、前記デバッガプロセスを前記ソフトウェアプロセスから分離することを更に含む請求項１〜５のいずれか１項に記載の方法。
7. 前記ソフトウェアプロセスは、プログラムとして実行可能なファイル、例えばアプリケーションを実施する請求項１〜６のいずれか１項に記載の方法。
8. 前記ソフトウェアプロセスは、ライブラリを実施する請求項１〜６のいずれか１項に記載の方法。
9. 請求項１〜８のいずれか１項に記載の方法を実行するためのコンピュータ実行可能なコードを含むコンピュータ実行可能なプログラム製品。
10. 請求項１〜８のいずれか１項に記載の方法を実行するように構成される装置。
11. 保護されたコードを生成する方法であって、
    デバッガに移行するオブジェクトコード中のコードフラグメントを識別するステップと、
    実行時にデバッガプロセスにソフトウェアプロセスにアタッチさせるバイナリコードを生成するステップであって、前記識別されたコードフラグメントは前記デバッガプロセス内に実行されるステップと、
    を含む方法。
12. 前記生成するステップは、汎用デバッガ機能に対応する所定のコードを前記バイナリコードに組み込むことを含む請求項１１に記載の方法。
13. 前記バイナリコードは、前記ソースコードに対応するが、前記識別されたコードフラグメントを除外する第１のバイナリ・コード・ファイル及び前記デバッガに対応する第２のバイナリ・コード・ファイルを含む請求項１１又は１２に記載の方法。
14. 請求項１１〜１３のいずれか１項に記載の方法を実行するためのコンピュータ実行可能なコードを含むコンピュータ実行可能なプログラム製品。
15. 請求項１１〜１３のいずれか１項に記載の方法を実行するように構成される装置。

Images