DLL注入を防ぐ方法
先日、私はこれを見ました：
http://www.edgeofnowhere.cc/viewtopic.php?p=2483118
DLL注入の3つの異なる方法を超えています。これらをプロセスから防ぐにはどうすればよいですか？または最低限、最初の方法を防ぐにはどうすればよいですか？
おそらく、Ring 0ドライバーが3つすべてを停止する唯一の方法かもしれないと思っていましたが、コミュニティの考えを知りたいのですが。
最適な技術的解決策は、プロセスの初期化後にローダーコードが正しく実行されないようにすることです。これを行う1つの方法は、NTローダーロックを取得することです。これにより、ローダーアクションが実行されなくなります。その他のオプションには、ローダーコードをメモリに直接パッチして、攻撃者がLoadLibraryの呼び出しを失敗させることが含まれます（たとえば、予想されるケースを処理するためのint3ブレークポイントの挿入と自己デバッグ）。
しかし、ハッカー（実際には、リンク先のサイトを管理している人）として言えば、何らかの方法でユーザーがプロセスにコードを取り込むのを阻止することはできません。 LoadLibraryはたまたま便利なショートカットですが、非常に複雑なring0コードを除いて、完全に停止することを決して望めない、コードを手動でロードするさまざまな方法があります。そして、あなたがring0に行っても、ハッカーはあなたのすぐそばにいます。
また、DLLインジェクションの正当な使用法はたくさんあります。テーマプログラム、アクセシビリティツール、およびOSの機能を拡張するさまざまなプログラムは、すべてDLLへのインジェクションを使用できます。プログラムに機能を追加します。
これらの3つのテクニックから身を守る方法：
CreateRemoteThread
LoadLibraryをフックすることにより、最初の手法（LoadLibraryを呼び出すCreateRemoteThread）を防ぐことができます。フックでは、プロセスの一部であり、ロードされる可能性があることがわかっているDLL名のリストに対してチェックするか、ロードしたくない既知のDLLのリストに対してチェックできます。
DLLが見つかった場合、SetLastError（ERROR_ACCESS_DENIED）をロードしたくないのでNULLを返します。最後のエラーを設定して、エラーコードを探すコードを書く人がエラーを取得できるようにしました。これは機能しているようですが、おそらく別のコードの方が適切な場合があります。
これにより、DLLのロードが停止します。
SetWindowsHookEx
CreateRemoteThreadブロッキングの同じ手法はSetWindowsHookExでも機能すると思いますが、SetWindowsHookEx手法がコードのロードを開始する前にフックをインストールできる場合に限ります（通常、最初のウィンドウがアプリで作成されたとき-存続期間の早いため） ）。
コード洞窟
素晴らしいテクニック。その前に見たことがない。これを防ぐことはできますが、Code CaveがLoadLibraryを直接呼び出すため、（IATテーブルではなく）LoadLibraryエントリポイントをフックする必要があります。
記事の著者がコメントしたように-あなたが攻撃される可能性がある多くの方法があり、おそらくそれらすべてを倒すのに苦労するでしょう。ただし、特定のDLLの負荷（サードパーティDLLがなかったためにソフトウェアと互換性のない特定のサードパーティDLLなど）に対してのみ防御したい場合がよくあります。別のフックも存在する可能性があるという事実に対応するように適切に記述されているため、ロードをブロックします）。
最善の方法は、信頼できないプロセスが管理者アクセス権を取得したり、アプリケーションと同じユーザーアカウントとして実行したりしないようにすることです。このアクセス権がないと、アプリケーションへのコードインジェクションは不可能です。そして、そのようなプロセスがそのアクセス権を取得すると、別のプロセスに自分自身を注入する必要なしに、あらゆる種類のいたずらを引き起こす可能性があります-注入は単に隠すのを容易にするだけです。
このポスターは、彼がゲームのアンチハッキングに投資していることを示唆しているので、私が考えていることについて少し説明します。元詐欺師として。
ゲームのアンチハッキングについてのポインタ。
最善の方法はサーバーにコアゲームロジックを実行させるです。例えば一人称シューティングゲームで、クライアントがサーバーに送信する動きを監視します。それらがランダムに動き回ることを許可しないでください。 サーバーが各プレーヤーが独自のロジックに基づいている場所をクライアントに通知できるようにします。コマンドを転送するだけではいけません。彼らは偽物である可能性があります。
ハッカーが自分のクライアントをハッキングしたかどうかは誰が気にしますか？他のものにそれを拒否し、すべてが良いです。スタークラフトマップハックの場合、解決策は簡単です。不明な領域のゲーム状態を公開しないでください。帯域幅も節約できます。
私はデルタフォース（その古いゲーム）の大きな詐欺師でした。私が使用した主なトリックは、プロセスメモリを直接変更して、ゲームのどこにでもワープすることでした。いいえDLLが必要です！
次に、Ring3ソリューションをお探しですか？もしそうなら、あなたは現在（少なくとも私の知る限りでは）箱から出して提供されていない追加の機能をシステムに組み込みたいので、いくらかの作業が必要になります。また、これはドライバーからも可能です。実際、ほとんどのAVソフトウェアはこの種のアクティビティを定期的に実行します。
上記のメソッドをユーザーモードから停止することについては、プロセスの作成またはDLLの読み込み）へのコールバックとして自分自身を登録することはできないため、少しトリッキーになります。ただし、プロセスがプロセスの前に開始されたと想定し、CreateRemoteThreadおよび類似の関数をグローバルにフックして、このタイプのチェックを自分で実行します。
したがって、実質的には、CreateRemoteThreadがスレッドを作成する場所を確認し、満足できない場合はエラーを返します。
これは最初の2つの方法を無効にします。 3番目の方法では、ディスク上に元のプログラムの有効なハッシュがある場合は、ロードする前に常にハッシュを確認できます。ハッシュがない場合は、少なくとも、誰かがそのタイプのコードを追加する単純な場所のいくつかをチェックして、そこにあるとは思わないDLL（たとえば、IAT、または実行文字列）を探すことができます。
これは完全な保証ではありませんが、要求した機能を提供するようです。
議論のための簡単な考え:)
コードケーブを使用してCRCチェックを独自のコードに挿入すると、他のコードケーブの使用が遅くなる可能性があります。
ロードされている不明なdllについてプロセスモジュールリストをポーリングすると、アタッチスレッドとメッセージフックを使用して古いものを挿入するだけで、人々の速度が低下する可能性があります。
私はWindows APIに精通していませんが、より一般的なポインタをいくつか紹介します。
Windowsデータ実行防止（DEP）を使用できるかどうかを確認します。リンクで概説されているプロセスはOSの観点からは有効なプロセスであるため、おそらくすべての（読み取り：ほとんどの）状況では機能しません。深層防御
プロセスメソッドがアプリケーション全体でセキュリティ権限をアサートすることを確認します
メモリスペースを静的に割り当てて、その中に生成された新しいスレッドが失敗するか、既存のメモリスペースを上書きするようにします。ただし、これを検出して修正するには、おそらくかなりの量のロジックが必要です。
コードをデバイスドライバーまたはWindowsファイル保護の傘の下でカバーできるその他の低レベルタイプのプロセスに組み入れます。
Cthulonの答えを見ただけで、おそらく彼は正しいと思います。アプリケーションでコードインジェクションを実行したい人なら誰でもそうする方法を見つけるでしょう。上記の手順では、少し難しくなるだけかもしれません。
お役に立てれば
なぜこれを防ぎたいのですか？それは実際の「ビジネス」ニーズですか、それとも「ハック」に反対する「ハック」に興味があるだけですか
ユーザー権限でこれが許可されている場合、それは仕様によるものです。OSは、システムの管理者が実行するアカウントに割り当てられているyoという機能をすべてのユーザーに提供します。
レイモンド・チェンはすぐにここにリンクします...