アプリケーション（App）がファイルを開くプロセスは、NTFSやFAT32などのファイルシステムにカーネルモードに配置されているため、ファイルを開くのにもWindows APIによる多層チェックを経て、ユーザーモードからカーネルモードに進入してから、最後にカーネルモードのNTFSやFAT32などのファイルシステムを使用することができます。
以下の例では、Notepad.exeとWinword.exeがファイルを開くプロセスを表示しています。
ユーザモード
Windowsシステム全体を、上部のユーザモードと下部のカーネルモードに分けます。
上部のユーザモードでは、各アプリ（アプリケーション）は自分がユーザーモード全体の仮想メモリスペースを所有していると認識しており、Windowsは各アプリが交代で動作できるようにタイムシェアリングの仕組みを使用します。
各アプリはそれぞれ専用のライブラリを使用します。例えば、Notepad.exeは自身専用のライブラリKernel32.DLLおよびntdll.DLLを所有しています。Winword.exeも自身専用のライブラリKernel32.DLLおよびntdll.DLLを所有しています。
Notepad.exeがファイルを開く必要がある場合、最初に専用のライブラリを通過する必要があります。例えば、Kernel32.DLLのCreateFileWやKernel32.DLLのNtCreateFileなどを使用して、最後にfastsystemCallを介してカーネルモードに進入します。
同様に、Winword.exeがファイルを開く場合も右側の紫色の線に従って、自身の専用ライブラリを使用して最後にカーネルモードに進入する必要があります。
カーネルモード
前述のように、ユーザモードでは、各アプリ（アプリケーション）が独自の世界を持っていて干渉しません。したがってNotepad.exeがクラッシュしてもWinword.exeに影響はありませんが、カーネルモードに入ると単一の世界しかありません。
ファイルを開く流れについて説明を続けます。下部のカーネルモードでは（1）システムサービスディスパッチャーは実際にはカーネルAPIのマッピングテーブルであり、このテーブルを経由して対応するカーネルAPIにジャンプします。以前は多くのハッカープログラムがこのジャンプポイントを変更してカーネルAPIを簡単にキャプチャしていましたが、その後Windowsはこのテーブルを保護するようになり、ハッキングによるジャンプテーブル変更を防止するようにしました。
その後NtCreateFileが続きますが、このカーネルAPIはNtOsKrnlによって提供されるもので、ユーザモードのKernel32.DLLが提供するNtCreateFileとは異なります。混同しないように注意してください。
次に、I/Oのサブシステムがあります。このサブシステムの呼び出しとパラメータの受け渡し方法は大きく変化し、一般的に知られているAPIコールではありません。これは、I/Oのサブシステムがこのファイルを開くコマンドをパラメータと一緒に独自のI/Oリクエストパケット構造に変換するためです。これを通常「IRP」と呼びます。IRPの動作原理はWindows Messageのようなもので、ドライバを開発するときに使用する重要な構造体です。ドライバを書くためにはIRPの構造を把握する必要があります。
実際の動作では、I/OのサブシステムはIRPを低レベルのドライバに送信します。通常これらのドライバは制御に使用できます。レイヤーごとのドライバチェックやフィルタリングを経て、最後にNTFSまたはFAT32などのファイルシステムに到達して、これらのファイルシステムが実際にファイルを開く動作を実行します。
制御時は最初にCreateFileのフックポイントを設計する
前述のように、アプリケーションがファイルを開く場合、多くのWindows APIを経由して、ユーザモードとドライバモードの2つの領域をまたいでファイルシステム（NTFSまたはFAT32）にアクセスする必要があります。
したがって、アプリケーションのファイルオープンをインターセプトする方法は多岐にわたります。
まず、ユーザモードまたはドライバモードのどちらでインターセプトするかを決めます。2つのインターセプト方式は実装方法が異なります。ユーザモードのAPIフック方式や原理に興味がある場合は、以前ファインアートが発表した技術文書の参照をお勧めします。TSF製品はユーザモードのAPIフックを使用した防御システムです。
ドライバによるコントロール
ドライバには大きな権限があり、通常実現不可能な機能を実現できるため、特殊制御の選択肢としてよく使われます。しかし、欠点も明らかです。ドライバの実装自体が困難で技術的なハードルも高いため、開発者の不注意でWindowsが不安定になる可能性が大きいです。不安定になった結果、ブルースクリーンエラー（BSOD）が発生することもよく見られます。もちろん、安全にドライバを実装することができれば、ドライバを使用した制御は非常に目覚ましい成果をもたらしてくれます。
システムセキュリティ的にもドライバによる制御は優れています。なぜなら、64ビットのWindowsではドライバのインストールにMicrosoftのデジタル署名が必要であり、Microsoftのチェックをクリアする必要があるためドライバによるPCへの侵入を防止できるからです。
長所
- ドライバの権限が高く、多くのことができる
- 異なるユーザやアプリケーションを制御できる
- 単一のプログラムで制御できる
- ドライバのインストールにはマイクロソフトの署名が必要で偽造されにくい
- ユーザがログインしなくても制御できる
短所
- 開発のハードルが高く、開発が難しい
- 問題が発生するとBSODを引き起こす可能性がある
- 64bitのWindowsにおいて、ドライバのインストールにはマイクロソフトの署名が必要
- ドライバのテストが比較的困難
- Windowsの互換性要件が高く、例えばアンチウイルスソフトウェアと競合しやすい