以下の質問は、教育目的のみのものであり、説明されている機能は、登録されたDLLを変更したり、マルウェアを開発するのではなく、元のDLLの代わりにカスタムDLLをロードする
最近私は、アプリケーション独自のDLLではなく、独自のカスタムDLLを読み込むいくつかの方法を検討してきました。 来た方法の1つは、<exe>.localメソッドでした。
この方法で少し経験した後、レジストリからKnownDllsエントリを削除した後、一部のシステムDLLをパッチされたDLLに置き換えることができました。
これらは、DLLです：
しかし、のDLLは、ローカルフォルダにあります。
しかし、system32からロードを主張するいくつかのDLLがまだありますディレクトリにありますが、それらはローカルフォルダに存在します。
私はDLLをsystem32フォルダの代わりにローカルフォルダからロードする方法はありますか？
Windowsローダーの動作を見てください。これはOSのバージョンに依存しますが、それらのDLLのいくつかはプログラムの前にロードされ、ローダーはシステムによって提供されるパス上でそれらを常に探します。 WinDbgでプログラムを起動してシーケンスを見てください。
これは、まばゆい、資源が不足している脳ダンプのような答えではありません。
私はあなたの結果に驚かない理由を説明するのに役立ちます。これは、私にとって、CreateProcessとLoadLibraryの間の重大な違い、そしてWin32の処理の仕組みにまでわかります。
通常、LoadLibraryを使用する場合は、DLLをロードするプロセス内から使用しています。そのため、起動コンテキスト、dll検索パスなど、app.localフラグのようなものの知識を含むインプロセスコンテキスト情報のすべてを活用することができます。 これらの値はすべて現在のプロセスに固有であり、このようなものを追跡するのは他のプロセス（またはカーネル）の仕事ではありません。
しかし、CreateProcessを見ると、いくつかの問題があります。それが最初に呼び出されるとき、それは起動のコンテキストで呼び出され、宛先、プロセスではないので、宛先のアクティベーションコンテキストを何も知らない。実際、宛先プロセスはまだ存在しません。
CreateProcessの実装では、NTプロセスを作成し、現在のプロセスでプロセスコンテキストのものすべてをインスタンス化する意味がないため、できるだけ早くプロセスロードを実行する必要があります。
しかし、それには、宛先プロセスに少なくともいくつかのコードが必要です：EXEファイルヘッダーの解析、ヘッダーの抽出、および残りの読み込みに使用されるアクティベーションコンテキストの構築を担当するカーネルコードdll。
これは残念ながら、kernel32です。dllやいくつかの依存関係は、そのプロセスがapp.localフラグなどに気づいてdll検索コンテキストを構築できるようになるまで、プロセスにマップされる必要があります。
それは本当に少し散歩です。おそらく最も重要なことに、 'CreateProcess'は実際にはそれほど多くの作業をしません。カーネルコードを起動し、新しいプロセスを作成し、いくつかのコアDLLをマップして、新しいプロセスの実行を開始します。しかし、それはすべて 'CreateProcess'ではありません。 'NtCreateProcess'を見てみましょう – MSalters
これはマルウェアです。これらのDLLは、プロセスの起動時にロードされます。 –
@DavidHeffernanこれはマルウェアではありません。これは、新しいバニラウィンドウ10仮想マシンです。 – Aviv
システムDLLの代わりにしようとするプログラム –