1

x86 での "int" 命令には特権がないという印象を受けました。したがって、この命令をユーザー空間アプリケーションから実行できるはずだと考えました。しかし、そうではないようです。

Windows のユーザー アプリケーションから int を実行しようとしています。そうするのは正しくないかもしれないことはわかっています。しかし、私は少し楽しみたいと思っていました。しかし、ウィンドウが私のアプリケーションを殺しています。

問題は条件 cpl <=iopl によるものだと思います。誰もそれを回避する方法を知っていますか?

4

3 に答える 3

3

一般に、カーネルサービスを呼び出すためにユーザーモードコードがカーネルモードに移行するための古いディスパッチャーメカニズムは、によって実装されていましたint 2Eh（現在はに置き換えられていsysenterます）。またint 3、今日までブレークポイント用に予約されています。

基本的に、カーネルは特定の割り込みに対してトラップを設定し（ただし、すべてかどうかは覚えていません）、トラップコードに応じて、ユーザーモードの呼び出し元に対して何らかのサービスを実行します。それが不可能な場合は、アプリケーションが強制終了されます。特権操作。

詳細はとにかく、あなたが呼び出そうとしていた正確な割り込みに依存します。たとえば、関数DbgBreakPoint（ntdll.dll）とDebugBreak（ ）は、呼び出し（または実際には特定のオペコード）kernel32.dll以外は何もしません。int 3int3

編集1：新しいWindowsバージョン（XP SP2以降、IIRC）では、回答に書いたようにsysenter置き換えられます。int 2Eh終了する理由の1つとして考えられるのは、例外処理によってこれをキャッチできるはずですが、スタックで期待されるパラメーターを渡さないためです。基本的に、ネイティブAPIのusermode部分は、呼び出すシステムサービスのパラメーターをスタックに配置し、サービスの番号（システムサービスディスパッチテーブルのインデックス-SSDT、場合によってはSDT）を特定のレジスタに配置してから呼び出します。新しいシステムsysenterと古いシステムint 2Eh。

于 2012-05-04T23:26:04.307 に答える
2

特定の割り込みベクトルの最小リングレベル（特定の「int」に特権があるかどうかを決定する）は、割り込み記述子テーブル内のベクトルに関連付けられたリングレベル記述子に基づいています。

Windowsでは、割り込みの大部分は特権命令です。これにより、ユーザーモードが単に二重障害ハンドラーを呼び出してOSのバグチェックをすぐに行うことができなくなります。

Windowsには、特権のない割り込みがいくつかあります。具体的には：

  • int 1（EFLAGS_TFがeflagsに設定されている場合、CD 01エンコーディングとデバッグ割り込みの両方が単一の命令の後に発生します）
  • int 3（CCとCD 03の両方のエンコード）
  • int 2E（Windowsシステムコール）

他のすべての割り込みには特権があり、それらを呼び出すと、代わりに「無効な命令」割り込みが発行されます。

于 2012-05-10T08:43:08.240 に答える
0

INT は「特権制御」命令です。カーネルがユーザーモードから自分自身を保護するには、このようにする必要があります。INT は、ハードウェア割り込みとプロセッサ例外が通過するのとまったく同じトラップ ベクターを通過するため、ユーザーモードがこれらの例外を任意にトリガーできる場合、割り込みディスパッチ コードが混乱します。

Windows によってまだ設定されていない特定のベクターで割り込みをトリガーする場合は、デバッガーまたはカーネル ドライバーを使用して、その割り込みベクターの IDT エントリを変更する必要があります。Patchguard では、x64 バージョンの Windows のドライバーからこれを行うことはできません。

于 2012-05-06T16:53:22.800 に答える