どうすれば別のプロセスに寄り添うことができますか? 同様に、別のプロセスの名前を共有しますか? 私のアプリケーションが griddemo.exe で、たとえば explorer.exe を使いたい場合、それは可能でしょうか? kernel32 の CreateRemoteThread() について読んでください。それは正しい方向ですか?セキュリティ/UAC の問題はありますか?
4 に答える
まず最初に申し訳ありませんが、私の回答は別の回答として長くなります。
私は何年もの間、さまざまなバージョンのオペレーティング システム (Windows NT 4.0 から Windows 7 まで) で DLL インジェクションを使用してきましたが、ウイルス スキャナー (さまざまなバージョンの Norton と McAfee の両方を含む) に問題はありませんでした。したがって、私はこの点で Stephen Cleary (彼の回答を参照) に同意しません。
の使用は、CreateRemoteThread()
実際には方法の 1 つにすぎません。AppInit_DLLsは別の方法です。どちらにも長所と短所があります。AppInit_DLLs の主な利点は、任意のプロセスに DLL を簡単に挿入できることです。AppInit_DLLs アプローチの主な欠点は次のとおりです。
- すべての GUI アプリケーションが DLL をロードします。explorer.exeのように 1 つのプロセスでのみロードする場合は、これを行うことはできません。そのため、すべての GUI プロセスの作業スペースが DLL によって増加します。DLL のエラー (特に、DLL の依存 DLL 内
DllMain
または依存 DLL 内) は、現在不明な多くのプロセスをクラッシュさせる可能性があります。 - コンソール アプリケーションまたは User32.dll に依存しない EXE で AppInit_DLLs アプローチに関して DLL を挿入することはできません。
- User32.dll が完全に初期化される前
DllMain
に呼び出されるため、の内部では十分に注意する必要があります。したがって、DLL 内で使用できる安全な DLLは Kernel32.dll です。DllMain
に関してはCreateRemoteThread()
、プロセスで追加のスレッドを開始できます。の主な問題CreateRemoteThread()
は、そのlpStartAddress
パラメータがリモート プロセスからのアドレスでなければならないことです。したがって、 functions を使用OpenProcess
しVirtualAllocEx
てWriteProcessMemory
、宛先プロセスのメモリに情報を書き込む必要があります。プロセスを開くには、デバッグ権限を有効にする必要があります。宛先プロセス内で 2 + 2 のみを実行する場合は、対応するバイナリ コードを宛先プロセスに直接コピーできます。本当に興味深い作業はすべて、Windows API を使用して行うことができます。したがって、ほとんどの人はコードをコピーしません。その1回の呼び出しの代わりにLoadLibrary("MyPath\\MyDll.dll"
、宛先プロセス内で)。の原型はのの原型LoadLibrary
と同じだThreadProc
からCreateThread
ofLoadLibrary
として呼び出すことができます。この方法にはDLL インジェクションという名前が付いています。ThreadProc
CreateRemoteThread()
本当に必要な場合にのみ、この DLL インジェクションを使用することをお勧めします。目的のアプリケーションに、プロセス内で DLL をロードするプラグインなどの他の方法がある場合は、DLL インジェクションの代わりにこの方法を使用する必要があります。
DLL インジェクションの実際の例を理解した後で解決しなければならないいくつかの一般的な問題。この問題は最初はわかりませんが、アプリケーションを長時間使用すると、その重要性がわかるでしょう。
- を使用する前に、宛先プロセスがすでに実行されている瞬間を見つける必要があります
CreateRemoteThread()
。 - を呼び出す前に、宛先アプリケーションがすでに初期化されている必要があります
CreateRemoteThread()
。したがって、CreateRemoteThread()
早すぎて使用しないでください。explorer.exe の場合、Run レジストリ キーから小さなトリガー プログラムを開始できます。現在のところ、explorer.exe は DLL インジェクションの準備が整っています。 - Windows の 64 ビット バージョンを考慮する必要があります。
- 宛先プロセス内の DLL 再配置を忘れないでください。プロセスと同じように、DLL を別のアドレスの宛先プロセスにロードできることに注意してください。ほとんどの場合、挿入する DLL に適したベース アドレス (リンカー オプション) を選択することをお勧めします。Kernel32.dll は、ソース プロセスのように別のアドレスに読み込まれることがあります (めったにありません)。この問題のない DLL インジェクション コードを作成できます。
- ターミナル サービスは、設計上、各ターミナル セッションを分離します。したがって、
CreateRemoteThread
ターゲット プロセスが呼び出しプロセスとは異なるセッションにある場合、失敗します。XP (ドメインに接続されていない)、または Windows サービスから DLL インジェクションを実行しようとすると、特に Vista または Windows 7 で発生する問題。この問題を解決するには、宛先プロセスと同じターミナル セッションで実行されているプロセスから DLL インジェクションを作成するか、または を使用する前に現在のセッションを切り替える必要がありCreateRemoteThread
ます。プロセスはSE_TCB_NAME
権限を有効にして、パラメーターを使用するSetTokenInformation
必要がありTokenSessionId
ます。宛先プロセスのセッション ID を取得するには、さまざまな方法を使用できます。接頭辞 WTS ( などWTSGetActiveConsoleSessionId
) が付いた関数は非常に便利です。
ですから、すべてが簡単というわけではありませんが、オペレーティング システムについてさまざまなことが学べる非常に興味深い科目です。プロジェクトの要件に対応する 1 つの方法を選択してプログラミングを開始する前に、問題とそれを解決するためのさまざまな方法を分析するために少し時間を費やすだけでよいでしょう。
DLL インジェクションは、これを行う従来の方法です。特に、ウイルス スキャナは実際の作業を不審に思っているため、非常に注意が必要です。したがって、たとえそれが機能したとしても、ノートン/マカフィーはあなたをブロックする可能性が高く、将来ブロックする可能性があります.
DLL インジェクションの簡単な方法の 1 つは、AppInit_DLLs レジストリ値です。Microsoft は、この機能を単純に削除する権利を留保していることに注意してください (将来的には削除する可能性があります)。
Microsoft が承認した DLL インジェクションを実現する方法は、Microsoft Detoursのライセンスを取得することです。
DLL インジェクションを安全に実行するには、CLR バージョン 4.0 以降に対して DLL をビルドする必要があることに注意してください。これは、インプロセス サイド バイ サイドをサポートする最初のバージョンであるためです。
コードを別のプロセスに挿入することを意味する場合、dll インジェクションは 1 つの手法です。
http://en.wikipedia.org/wiki/DLL_injection
何年もこれを行っていないので、最新の MS Windows オペレーティング システム (つまり、XP 以降) がこれでどれほど満足するかわかりません。
私は最近これを試していませんが、これを行う別の方法は、フック DLL を作成することです。
MessageProcのようなフック プロシージャを含む DLL を作成します。
この DLL を Windows\System32 にインストールします。
FindWindows(Ex) を使用して、被害者プロセスのウィンドウを見つけます。
GetWindowThreadProcessId () を使用して、そのウィンドウの所有スレッドを見つけます。これは、システム上のすべてのプロセスに DLL を挿入することを避けるために必要です。
そのスレッドをフックするには、 SetWindowsHookExを使用します。
ウィンドウに WM_USER メッセージを PostMessage します - フック DLL がまだアクティブになっていない場合はアクティブにします。
十分な権限を持っていないユーザーの場合、これにより新しいWindows Vista/7 UIPI/UACが呼び出される可能性がありますが、これは多くの要因によって異なります。マイレージは異なる場合があります。