StackOverflow の質問「 C# Theoretical: Write a JMP to a codecave in asm 」で初めてこの単語に遭遇しました。Wiktionaryによると、コード ケーブは次のとおりです。
誰か (通常はソフトウェア クラッカー) がカスタム プログラミング コードを挿入してプログラムの動作を変更するために使用できる未使用のメモリ ブロック。
正しい定義を見つけましたか? もしそうなら、コード ケイブの正当な使用法はありますか?
StackOverflow の質問「 C# Theoretical: Write a JMP to a codecave in asm 」で初めてこの単語に遭遇しました。Wiktionaryによると、コード ケーブは次のとおりです。
誰か (通常はソフトウェア クラッカー) がカスタム プログラミング コードを挿入してプログラムの動作を変更するために使用できる未使用のメモリ ブロック。
正しい定義を見つけましたか? もしそうなら、コード ケイブの正当な使用法はありますか?
自己変更コードの使用の一環として、コード ケーブを意図的に作成したい場合があります。
もちろん、それが狂っていると仮定して。
私はそれらを使ったことがありますが、今日までコード ケーブという用語を聞いたことがありませんでした。ウィクショナリーの定義によると、コード ケーブとは、クラッカーがクラックしようとしている実行可能ファイルの中で見つけたものです。あなたが引用した質問は、そのように使用していません。VirtualAllocEx
代わりに、ターゲット プロセスで新しいメモリ ブロックを作成するために、コード ケーブが割り当てられていることを示唆しています。これにより、ターゲット内の未使用スペースを検索する必要がなくなり、すべての新しいコードを配置するのに十分なスペースが確保されます。
結局のところ、 「コード ケーブ」は実行時に生成されたコードを格納する場所に過ぎないと思います。そのコードに悪意のある目的がある必要はありません。そしてその時点で、コード ケーブとは何かという問題はまったく面白くなくなります。興味深いのは、実行時にコードを生成する理由と、必要なときに新しいコードを確実に実行するための手法です。
コード ケーブは、通常、整列のためにコンパイラによって作成され、多くの場合、関数間に大量に配置されます。また、構造とジャンプの間にコード ケーブがあるはずですが (一部のアーキテクチャでは)、通常はそれほど多くはありません。
ゼロ化されたメモリのブロックを検索することもできますが、プログラムがそれらを使用しないという保証はありません。
理論的には、ソースコードを紛失した場合、それらを使用してバグのあるプログラムにパッチを当てることができ、プログラムのサイズは大きくなりません。
編集
コード ケーブは実行時に生成されたコード専用であると示唆している方へ: それは不完全な定義です。私は何度も「コードの洞窟」にデータ構造を書き、そこを指すようにポインターを更新しましたが、そうしているのは私だけではないと思います。
いくつかの正当な用途: 再起動せずにライブ OS バイナリにパッチを適用する (MS がこれを行う)、ファイアウォールとウイルス対策のために低レベル OS 機能 (ファイルシステム、ネットワーク) をフックする、ソース コードがない場合にアプリケーションを拡張する (低レベル OS 呼び出しをスクレイピングするなど)目の不自由な人のために声を出して読むことができるように、DrawText に)
この用語にはなじみがありませんが、ホット パッチ メカニズムでは、コード パッチを格納するために予約済みの領域を使用できます。欠陥のある関数にフックし、新しく改善された関数にリダイレクトします。重要な機器 (大規模な通信スイッチ) を停止することなく、オンザフライで実行できます。
実行時にコードを挿入するために使用できます。OSで許可されている場合(NXビットが設定されていないなど)、静的言語で自己変更コードを記述するために使用できます。用途はありますが、通常のビジネス アプリでは考えるべきことではありません。
自己変更コードは軽く考えるべきではありませんが、パフォーマンスが大幅に向上する場合があります。非常に長い間プログラミングをしている場合は、おそらく気付かずに使用したことがあります。
486 以降が広く使用される前は、多くの PC にはハードウェア フローティング サポートが含まれていませんでした。これにより、人々は浮動小数点を含むプログラムを書く際にジレンマを抱えていました。インライン浮動小数点命令を使用するようにプログラムをコンパイルした場合、浮動小数点プロセッサを搭載したマシンでは高速に実行されますが、浮動小数点プロセッサを搭載していないマシンではまったく高速に実行されません。ソフトウェア浮動小数点エミュレーションを使用してプログラムをコンパイルした場合、すべてのマシンで実行されますが、ハードウェア浮動小数点を使用するマシンでも速度は遅くなります。
多くのコンパイラ ライブラリは、自己変更コードで興味深いトリックを使用しました。デフォルトの動作は、浮動小数点演算が必要な場所にトラップ命令を配置することでした。トラップ ハンドラは、ソフトウェアで命令をエミュレートするか、浮動小数点ハードウェアを備えたマシンで実行されていることを検出した場合、トラップ命令を適切なハードウェア浮動小数点命令に置き換えてコードを変更し、それを実行します。その結果、すべてのマシンで動作するソフトウェアが実現し、浮動小数点ハードウェアを備えたマシン上で、浮動小数点ハードウェアを直接使用するようにコードがコンパイルされているかのようにほぼ同じ速度で動作しました (ほとんどの浮動小数点集中操作は、何度も実行されるループで発生するため)。 )。
それは私にとって正しい定義のように思えます。
正当な使用については、次のように言わせてください。単純に実験のために実験を行っており、その結果を喜んで受け入れる場合を除き、使用しないでください。
この種のものを製品コードに入れる方法はありません。