2009-03-12 18 views
10

質問によると、LoadLibrary(Ex)の場合と同様に、ファイルではなくメモリ内の場所からDLLをロードします。私はWinAPIの専門家ではないので、googled少しと、かなり私のニーズを満たすMemoryModuleライブラリとthis articleを発見した。メモリ内の場所からDLLをロードする

一方、情報はかなり古いですし、ライブラリもしばらく更新されていません。だから私はそれを行うための異なった、より新しい、より良い方法があるかどうかを知りたがっていました。また、記事に記載されているライブラリを誰かが使用している場合、私はそれを使用する際に直面している可能性について洞察力を提供することができますか?

興味があるだけのもののために、私は、ディスク上の復号化されたバージョンを保存せずにアプリケーションのためのいくつかのプラグインを暗号化の概念を模索しています。

+2

(DLLヘッダが割り当てられた十分なスペースがあることを確認する)非圧縮のバイナリとにロードされたメモリを書き換えるのソースコードを使用する準備ができメモリからDLLをロードする方法: https://github.com/fancycode/MemoryModule – user1528094

答えて

3

まあ、these instructionsに従ってRAMドライブを作成し、その中のファイルをメモリにコピーしてLoadLibrary()を使用することができます。
インストールしたドライバ、インストール後の再起動、マイコンピュータの新しいドライブ文字に気付く人がいるため、これを何らかの製品として展開する予定がある場合、これはあまり実用的ではありません。また、これは実際には、誰もが見ることができるRAMドライブに座っているので、実際にDLLを隠すことはありません。

私が興味を持っているもう一つのことは、なぜ実際にこれをしたいのですか?おそらくあなたの最終的な結果は、メモリからDLLを読み込む以外の手段によっても達成できます。たとえば、UPXのようなバイナリパッカーを使用する場合、ディスク上にあるDLLは最終的に実行されるDLLとは異なります。直ちにDLLはLoadLibraryのと正常にロードされた後、アンパッカでキックとは、DLLがここ

+0

はい、私はUPXの動作を模倣し、私のアンパックを使用することができます/デクリプタをエントリーポイントとして使用し、メインアプリケーションとキーをネゴシエートできます。私はこの答えを受け入れるとマークします。数多くのアイデアのおかげで! –

5

独自のDLLローダーを実装することで、本当に素早く毛深くなることがあります。この記事を読んで、どのようなクレイジーなエッジケースを自分で得ることができるのか見逃しやすいのです。私はそれを強く勧めます。
あなたが実行しているコードがOSによって認識されているDLLの領域にリストされていないので、読み込み中のDLLのコードに対して従来のデバッグツールを使用することはできません。
もう1つの重大な問題は、ウィンドウでDEPを処理していることです。

+0

洞察をいただきありがとうございます。私はDLLローダーを再実装することは良い考えではないことに同意します。私はそれを行うための他の方法を探しています - おそらく、LoadLibraryやファイルシステムをどうにかして不正行為することは可能でしょうか。 –

+0

起因する問題は、ここでより詳細に記載されています:https://www.codeproject.com/Tips/430684/Loading-Win-DLLs-manually-without-LoadLibrary – Elmue

関連する問題