7

すべてのユーザー インタラクションをキャプチャするプロジェクトに取り組んでいます。MSDN は (これ)を伝えます

SetWindowsHookEx を使用して、DLL を別のプロセスに挿入できます。32 ビット DLL を 64 ビット プロセスに挿入することはできず、64 ビット DLL を 32 ビット プロセスに挿入することもできません。アプリケーションが他のプロセスでフックを使用する必要がある場合、32 ビット アプリケーションは SetWindowsHookEx を呼び出して 32 ビット DLL を 32 ビット プロセスに挿入し、64 ビット アプリケーションは SetWindowsHookEx を呼び出して 64 ビット DLL を挿入する必要があります。 DLL を 64 ビット プロセスに変換します。

私の質問は、アプリケーションが に対して構築された場合はどうなるかということですAny CPU。SetWindowsHookExに対してビルドされた DLLから呼び出す必要がありますかAny CPU。

HookFunctions_32.dll (x86 の両方) をロードする HookLogger_32.exe と、HookFunctions_64.dll (x64 の両方) の設定WH_CBTとWH_MOUSEグローバル (特定のスレッドではない) をロードする HookLogger_64.exe を作成しました。

HookLogger_32.exe、HookLogger_64.exe、HookFunctions_32.dll、および HookFunctions_64.dll は C++ で記述されています。

に対してビルドされた .NET アプリケーションをクリックするとAny CPU、これらの DLL が ( を介してSetWindowHookEx) 挿入されます。Windows OS がハングアップし、マシンを強制的に再起動する必要があります。

同じ .NET アプリケーションが x86 または x64 に対してビルドされ、HookLoggers (32 ビットと 64 ビットの両方) が開始された後にアプリケーションをクリックすると、すべて正常に動作します。

この未定義の動作の理由。

私が作業しているプラ​​ットフォームは 64 ビット マシンです。

4

4 に答える 4

3

DLL から対応する bitnse を挿入する必要があります。つまり、「任意の CPU」は実行時に 32 ビットまたは 64 ビットになります。DLL は実行時のビット数と一致する必要があります。

あなたの状況で役立つものは、「サイドバイサイドアセンブリ」（同じアセンブリの2つのバージョン、1つは32ビット、もう1つは64ビット）として知られています...これらが役立つと思います：

ここでは、多くの役立つ情報を含むすばらしいウォークスルーを見つけることができます。ネイティブ DLL を参照する C++/CLI DLL をラッピングする .NET DLLについて説明しています。

アップデート：

フックを本当に簡単かつ堅牢にするために、よくテストされたこの無料のライブラリを参照してください- 特に AnyCPU で動作します!

于 2012-02-04T20:10:37.787 に答える
0

32ビットコンピュータでは、AnyCPUアプリケーションが引き受けるビット数はかなり明白なはずです。

64ビットコンピューターには、ビット数ごとに1つずつ、2つの.NETFrameworkの個別のインストールがあります。ターゲットとしてAnyCPUを使用してコンパイルされた.NETアプリケーションは、通常64ビットインストールで実行されますが、x86を直接ターゲットとする別のアプリケーションによって参照される場合は、32ビットインストールでも実行できます。したがって、アプリケーションがどのように実行されているかを知っている場合にのみ、取得しているものを確認できます。独立したプロセスとして、または参照を介して。

私は何の仮定もしません。プロセスが64ビットコンピューターで64ビットであると想定しないでください。32ビットになる可能性があります。正しく実行されているモードを確認してください。次に、それに応じて32ビットまたは64ビットから挿入します。

ターゲットプロセスと同じビット数を使用する必要がある理由は、技術的な理由から、このようなフックはSysWOWバリアと呼ばれるものを越えることができないためです。SysWOWは、32ビットアプリケーションを64ビットコンピューターで実行したり、16ビットアプリケーションを32ビットコンピューターで実行したりできるようにするものです。SysWOWの異なる側で実行されているアプリケーション間で通信する場合、「障壁を越えて」います。 -つまり、1つはSysWOW（32ビット）内で実行されており、もう1つは（64ビット）ではありません。簡単に言えば、プロセスは完全にSysWOWの内外にある必要があります。したがって、32ビットコードを64ビットプロセスに追加することはできません。その逆も同様です。

于 2012-02-08T07:12:16.253 に答える
0

問題の説明から、私の推測は...任意のCPUコンパイル済みプログラムが32ビットフックを起動するx86スタブをロードしている場合、x86スタブは環境が64ビットをサポートしていることを確認して確認し、64ビットCLRバージョンを起動します。

このシナリオでは、32ビットフックdllがWH_SHELLメッセージを取得し、すでに終了しているプロセス（x86スタブ）に挿入しようとしている、または32ビットフックを64ビットCLRプロセスに挿入しようとしています。したがって、「非常にあいまいで、詳しく説明する必要がある」システムクラッシュが発生します。

コードが実際に何をしているのかを詳しく説明したい場合は、より多くのヘルプ（および一般化が少なく、「プログラムAを使用する」）が提供されます。実際にプロセスにコードを挿入していますか、それともプロセスのdwThreadIdを使用してSetWindowsHookExを呼び出していますか。

于 2012-02-07T13:04:26.830 に答える
0

あなたの主な問題は、ネイティブ プロセスに .NET アセンブリを挿入しようとしていて、それが確実に機能しないことだと思います。SetWindowsHookEx が CLR プロセスでの .NET アセンブリの挿入をサポートしているかどうかさえわかりません。あなたの問題の解決策は次のとおりです。

  1. x86 および x64 プラットフォーム用の C++/Delphi/VB などのネイティブ コンパイラを使用して、dll を書き換え/再コンパイルします。
  2. dll がシステム ライブラリのみに依存していることを確認してください。たとえば、ターゲット プロセスがクラッシュする可能性があるため、Windows に付属していない dll に依存するべきではありません。「Dependency Walker」ツールを使用して、依存関係を特定できます。
  3. MSDN に記載されているように、サポートする各 CPU に対して実行可能なインジェクターが必要です。この場合、x86 と x64 です。

または、madCodeHook や Detours などのより優れたインジェクション/フック ライブラリを使用できます。このようにして、彼らが提供する何十もの長所は言うまでもなく、問題＃3を克服します.

于 2012-02-04T22:57:25.260 に答える