問題タブ [dllmain]

Windows では、標準の DLL エントリ ポイントは DllMain と呼ばれます。2 番目のパラメータは DWORD ですul_reason_for_call。

MSDN でこの 2 番目のパラメーターの可能な値を調べました。次のことが明らかです。

しかし、どうですか：

このフラグを使用してエントリ ポイントが呼び出されるのはいつですか? DLL の「通常の」動作中に心配する必要がありますか?

DLL_PROCESS_VERIFIER2008 ではなく、Visual Studio 2005 のヘッダー ファイルにのみ表示されることに注意してください。

メモリ内の DLL から次の情報をクエリしたい:

• エントリ ポイントの正確なアドレス (DllMain?!)
• Dll のコード セクションのアドレスとサイズ
• 各 EXPORTED 関数のエントリ ポイントのアドレス

GetModuleInformation()PSAPI 関数から使用して、エントリ ポイントをクエリしました。しかし、MSDN によると、「これはDllMain関数のアドレスではありません」。

これらの情報を照会するためのライブラリ/API はありますか?

ハードコードされた文字列などに依存しない、この情報を照会する一般的な方法が必要です。

DLL をアンロードするときに、いくつかのオブジェクトを破棄する必要があります。このオブジェクトには、(接続を再接続するために) WSASocket 関数を呼び出すことがあるスレッドが含まれています。そのため、 に応答して DllMain からデストラクタを呼び出しますDLL_PROCESS_DETACHが、アプリケーションがハングします。具体的には、WSASocket の呼び出しがロックされます。

一部の関数、特に LoadLibrary と FreeLibrary を呼び出す関数は DllMain から呼び出せないことを知っています。しかし、なぜ WSASocket 関数にも同じ問題があるのでしょうか?

DllMain() の前に呼び出される関数は? C ランタイムの初期化中に複数の場合は、順序が重要です。

Borland C++ 5.02 で *.dll ファイルを作成しようとしましたが、この関数に問題があります。

プロジェクトをコンパイルしようとしましたが、コンパイラにエラーが表示されます。この関数またはこのコンパイラに問題があり、別のコンパイラとは型スタイルが異なりますか?

LoadLibrary および CreateRemoteThread アプローチを使用して、既存のプロセスに dll を挿入しようとしています。DllMain が何らかの理由で呼び出されていないという事実を除いて、私のコードはすべて美しく機能しています。

私は頭を悩ませ、できる限り多くのインターネット調査を行いましたが、どの提案も役に立ちませんでした.

dll をサンプル プロジェクトに静的にロードすると、見事に動作します。

LoadLibrary を使用してサンプル プロジェクトに dll を動的にロードすると、問題なく動作します。

DllMain が呼び出されないのは、LoadLibrary および CreateRemoteThread アプローチを使用してプロセスに挿入しようとしているときだけです。私は頭が痛いです！

SimpleDLL.dll ファイルがロックされており、notepad.exe を閉じるまで削除または上書きできないため、dll がインジェクターから notepad.exe プロセスに読み込まれることを確認しました。

参考までに、私のアイデアは Microsoft Visual Studio 2010 Ultimate です。

.

SimpleDLLCaller.cpp - これは正しく実行され、DllMain からのメッセージを出力します。これは、dll が正しく構築されていることを確認するために作成したプロジェクトです。私が見ることができる出力から、この方法でロードすると正しく動作しているように見えます。

SimpleDllCaller からの出力:

Simple Injector.cpp - これは SimpleDLLCaller とは別のプロジェクトであり、(notepad.exe が既に実行されている限り) 警告なしで正常にコンパイル/実行されますが、DllMain からのメッセージは表示されません。

シンプル インジェクターからの出力:

私がここで間違っていることを教えてください。どんなフィードバックでも大歓迎です。

SetWindowsHookExを使用して WH_GETMESSAGE、WH_CALLWNDPROC、および WH_CALLWNDPROCRET をフックするグローバル フックを作成しました。
フック dll は、フックされたプロセスに新しいスレッドを作成します。このスレッドは、とりわけ、プロセスのオーディオ状態をチェックし、IAudioSessionManager2::GetSessionEnumerator()を呼び出します。

ここで興味深いのは、フック ホストからUnhookWindowsHookEx()を呼び出していて、dll のワーカー スレッドがIAudioSessionManager2::GetSessionEnumerator()への呼び出しを実行している間に呼び出していたことです。その呼び出しは、 DLL_PROCESS_DETACH を持つ DllMainが呼び出された同じスレッドの呼び出しスタックにありました。その理由は、GetSessionEnumerator()がどこかでGetMessage()関数を呼び出し、後者が再入可能であるためだと思います。残念ながら正確には覚えていませんが、コール スタックで確認したと思います。

しかし、私が疑問に思っている重要なことや不明な点が複数あります。だからここに私の関連する質問があります：

1. DLL_PROCESS_DETACH を指定した DllMain は、現在アンロードされている dll から関数を実行するスレッドであっても、いつでも呼び出すことができますか?
2. DllMain DLL_PROCESS_DETACH が終了すると、関数のスタックはどうなりますか? 呼び出しスタックの上の関数のコードは最終的に実行されますか?
3. これらの関数が終了しない場合はどうなりますか? dll はいつアンロードされますか?
4. DllMain DLL_PROCESS_DETACH は、WH_GETMESSAGE、WH_CALLWNDPROC、および WH_CALLWNDPROCRET フックのコールバック中に同様に呼び出すことができますか? あまり頻繁ではありませんが、これらの関数は再入可能であるため、前の呼び出しがまだ同じスタックで実行されている間にこれらの関数への呼び出しを挿入できることを知っており、実験的に確認しましたが、次の呼び出しも行うかどうかはわかりませんDllMain も同様の方法で注入できます。
5. 正確に DllMain をスレッドで呼び出すことができる場合 - 呼び出す必要がある特定の Windows API 関数がいくつかあり、それが DllMain DLL_PROCESS_DETACH 呼び出しにつながる可能性がありますか、または任意の命令で発生する可能性がありますか?
6. DllMain DLL_PROCESS_DETACH 呼び出しをいつでも「注入」でき、コール スタックの上位の関数が実行されなくなった場合、コール スタックの上位の関数が中断された場所を正確に知るにはどうすればよいでしょうか? したがって、DllMain 内で関数によって割り当てられたハンドルまたはリソースをスタック上で解放することができます。
7. DllMain DLL_PROCESS_DETACH への呼び出しを一時的に防止/延期する方法はありますか? 呼び出し/割り込みが同じスタックで発生した場合、ロックは明らかに役に立ちません。

残念ながら、フック解除中に DllMain でこのような状況が発生する前に、フック (およびフック解除) コードを複数のコンピューターで数か月実行していたため、これらの質問を実験的に解決することはおそらくできません。なんらかの理由で、4つの異なるプログラムで同時に発生しました...

また、十分な評判を持っている人が「再入可能」と「再入可能」のタグをマージしてくれませんか?