4

背景情報を少し紹介します。私は、AppInit_DLLsレジストリ エントリを介して dll インジェクション手法で使用されている dll を置き換えることに取り組んでいます。その目的は、すべてのプロセスに存在し、GDI32.dll にフックを設定して、印刷に関する情報を収集することでした。これは、私たちが望むものを手に入れるための一種のファンキーな方法です。.dll 自体は 10 年以上前のもの (Visual Studio 97 で記述) であり、挿入された dll よりも少し侵襲性の低いものに置き換えたいと考えています。

おそらく私たちがSetWindowsHookEx()探しているもののようです。私はそれでいくつかの問題を抱えていましたが、このツリーが吠える価値があるかどうかについて同僚と話し合ったこともあります. 以下は、特定できなかったいくつかの質問です。

  1. たとえばStartDoc()GDI32.dll などの DLL からルーチンをフックすると、他のプロセスがその DLL からそのルーチンを使用するたびに通知を受け取るのでしょうか? これは、注入された .dll で取得していた機能の一種であり、今後も同じ機能が必要です。

  2. フックがトリガーされると、フック処理手順は、実際の呼び出しを開始したプロセスのプロセス空間で実行されますか?それとも、フックをセットアップしたプロセスのプロセス空間で実行されますか? 私の意見では、ルーチンを呼び出したプロセスのプロセス空間で実行する必要があります。たとえば、プログラムが呼び出す場合StartDoc()GDI32.dll から、フック処理プロシージャ コードがそのスペースに「注入」され、実行されます。それ以外の場合は、呼び出しプロセスとフックをセットアップするプロセスとの間で自動的にセットアップされるプロセス間通信が必要になりますが、そうではないと思います。また、このフック処理ルーチンが呼び出しプロセスのプロセス空間で実行される必要があるのは、それが知る必要があることの 1 つはその呼び出しプロセスの名前であるためです。実際にはそのプロセスで実行されていませんでした。

  3. フック処理ルーチンが .NET 管理環境を使用して記述されている場合、.NET 管理環境を利用していないプロセスにフックされると壊れますか? ここで C++ から離れて C# を使用したいのですが、管理されていないプロセスからフックが呼び出されたらどうなるでしょうか? 前に述べたように、フック処理手順は、フックされたルーチンを最初に呼び出したプロセスで実行されると思います。しかし、これが本当なら、このプロセスが .NET ランタイム環境を使用していないのに、着信フック処理コードが使用していると問題が発生すると思います。

4

1 に答える 1

3

  1. はい。

  2. 一般的には前者です。イベントをフックしているプロセスのコンテキストで実行されます。

    の呼び出しが成功するSetWindowsHookExと、オペレーティングシステムは、指定されたフックタイプの要件を満たすすべてのターゲットプロセスのアドレス空間にフックDLL（コールバック関数を含むもの）を自動的に挿入します。（もちろん、フックコードは必ずしもすぐに挿入されるわけではありません。）

    この一般的な規則の例外は、低レベルのキーボードとマウスのフック（WH_LL_KEYBOARDおよびWH_LL_MOUSE）です。これらのフックタイプはクライアントプロセスに挿入されないSetWindowsHookExため、コールバックは最初に呼び出されたのと同じスレッドで呼び出されます。

  3. 最後のポイントは、3番目の質問に答えるために覚えておくことが重要です。低レベルのキーボードとマウスのフックは、DLLインジェクションを必要としない唯一の2つのグローバルフックであるため、マネージド.NETコードで記述できる唯一の2つのタイプのフックでもあります。

    他のフックタイプについては、質問で表明された懸念は正確に正しいです。これらのフックDLLはCまたはC++で作成する必要があります。もちろん、アプリケーションの残りの部分は、管理された言語で作成することもできます。重要なのはフックDLLだけです。

MicrosoftDetoursまたはEasyHookのいずれかを検討することを検討してください。

于 2012-01-27T04:31:09.043 に答える