ランタイムコード変更のスマートなケースはありますか？

ランタイムコードの変更（実行時にプログラム自体のコードを変更するプログラム）の正当な（スマートな）使用について考えられますか？

最新のオペレーティングシステムでは、検出を回避するためにウイルスがこの手法を使用しているため、これを実行するプログラムを嫌うようです。

私が考えることができるすべては、コンパイル時に知ることができない実行時に何かを知ることによっていくつかのコードを削除または追加するような、ある種のランタイム最適化です。

コードの変更には多くの有効なケースがあります。実行時にコードを生成すると、次の場合に役立ちます。

• 一部の仮想マシンは、JITコンパイルを使用してパフォーマンスを向上させます。
• オンザフライで特殊な関数を生成することは、コンピュータグラフィックスでは長い間一般的でした。AppleによるOpenGLスタックでのランタイムコードの特殊化のためのLLVMの使用について、Blit（1984）のビットマップグラフィックスの Rob PikeとBart LocanthiとJohn Reiser ハードウェアソフトウェアのトレードオフ、またはChris Lattnerによるこの投稿（2006）を参照してください。
• 場合によっては、ソフトウェアは、スタック（または別の場所）でコードを動的に作成することを含む、トランポリンと呼ばれる手法を使用します。例としては、GCCの入れ子関数や一部のUnicesのシグナルメカニズムがあります。

時々、コードは実行時にコードに変換されます（これは動的バイナリトランスレーションと呼ばれます）：

• AppleのRosettaなどのエミュレータは、この手法を使用してエミュレーションを高速化します。もう1つの例は、Transmetaのコードモーフィングソフトウェアです。
• ValgrindやPinなどの洗練されたデバッガーやプロファイラーは、コードの実行中にコードを計測するために使用します。
• x86命令セットが拡張される前は、VMWare などの仮想化ソフトウェアは、仮想マシン内で特権x86コードを直接実行できませんでした。代わりに、問題のある命令をその場でより適切なカスタムコードに変換する必要がありました。

コード変更を使用して、命令セットの制限を回避できます。

• コンピュータがサブルーチンから戻る、または間接的にメモリをアドレス指定する命令を持っていなかった時代がありました（私は知っています）。自己変更コードは、サブルーチン、ポインタ、配列を実装する唯一の方法でした。

コード変更のその他のケース：

• 多くのデバッガーは、ブレークポイントを実装するために命令を置き換えます。
• 一部の動的リンカーは、実行時にコードを変更します。この記事では、Windows DLLのランタイム再配置に関するいくつかの背景情報を提供します。これは、事実上コード変更の形式です。

これはコンピュータグラフィックス、特に最適化のためのソフトウェアレンダラで行われています。実行時に多くのパラメータの状態が検査され、ラスタライザコードの最適化されたバージョンが生成されます（多くの条件を排除する可能性があります）。これにより、三角形などのグラフィックプリミティブをより高速にレンダリングできます。

ASMの命令セットは、あなたが可能性がいくつかの必要な指示、欠けているので、一つの正当な理由があるの構築自分自身を。例：x86では、レジスタ内の変数への割り込みを作成する方法はありません（たとえば、axの割り込み番号で割り込みを作成します）。オペコードにコード化されたconst番号のみが許可されました。自己変更コードを使用すると、この動作をエミュレートできます。

一部のコンパイラは、静的変数の初期化にこれを使用して、後続のアクセスの条件付きのコストを回避していました。つまり、最初に実行されたときに何もしないでコードを上書きすることにより、「このコードを1回だけ実行する」ことを実装しています。

多くの場合があります：

• ウイルスは通常、自己変更コードを使用して実行前にコードを「解読」しますが、この手法は、リバースエンジニアリング、クラッキング、および不要なハッカーのフラストレーションにも役立ちます。
• 場合によっては、実行中（たとえば、構成ファイルを読み込んだ直後）に、プロセスの残りの存続期間中、特定の分岐が常にまたはまったく行われないことがわかっている特定のポイントが存在する可能性があります。いくつかの変数をチェックして分岐する方法を決定します。分岐命令自体はそれに応じて変更できます
  • たとえば、仮想ディスパッチを特定の呼び出しに置き換えることができるように、可能な派生型の1つだけが処理されることが知られている場合があります。
  • 使用可能なハードウェアを検出すると、一致するコードの使用がハードコードされる場合があります
• 不要なコードは、ノーオペレーション命令またはそれを飛び越えて置き換えることができます。または、コードの次のビットを直接所定の位置にシフトさせることができます（位置に依存しないオペコードを使用する方が簡単です）。
• 独自のデバッグを容易にするために記述されたコードは、デバッガーが予期するトラップ/シグナル/割り込み命令を戦略的な場所に挿入する可能性があります。
• ユーザー入力に基づく一部の述語式は、ライブラリによってネイティブコードにコンパイルされる場合があります
• ランタイムまで表示されないいくつかの単純な操作をインライン化します（動的にロードされたライブラリからなど）...
• 自己計測/プロファイリングステップを条件付きで追加する
• クラックは、それらをロードするコードを変更するライブラリとして実装できます（正確に変更する「自己」ではありませんが、同じ手法と権限が必要です）。
• ...

一部のOSのセキュリティモデルでは、自己変更コードはroot / admin権限なしでは実行できないため、汎用的に使用することはできません。

ウィキペディアから：

厳格なW ^ Xセキュリティが適用されたオペレーティングシステムで実行されているアプリケーションソフトウェアは、書き込みが許可されているページで命令を実行できません。オペレーティングシステム自体のみがメモリに命令を書き込み、後でそれらの命令を実行できます。

そのようなOSでは、Java VMのようなプログラムでさえ、JITコードを実行するためにroot / admin特権が必要です。（詳細については、http：//en.wikipedia.org/wiki/W%5EXを参照してください）

合成OSは、基本的には、部分的にAPI呼び出しに対するあなたのプログラムを評価し、結果をOSのコードを置き換えます。主な利点は、多くのエラーチェックが廃止されたことです（プログラムがOSに愚かなことをするように要求しない場合、チェックする必要がないため）。

はい、それはランタイム最適化の例です。

何年も前に、ある朝、自己修正コードのデバッグに費やしました。1つの命令が次の命令のターゲットアドレスを変更しました。つまり、分岐アドレスを計算していました。それはアセンブリ言語で書かれていて、プログラムを1命令ずつ実行したときに完全に機能しました。しかし、プログラムを実行すると失敗しました。結局、マシンがメモリから2つの命令をフェッチしており、（命令がメモリに配置されているため）変更中の命令がすでにフェッチされていたため、マシンが変更されていない（正しくない）バージョンの命令を実行していた。もちろん、デバッグしているときは、一度に1つの命令しか実行していませんでした。

自己修正コードはテスト/デバッグが非常に厄介で、マシンの動作（ハードウェアであろうと仮想であろうと）に関する想定が隠されていることがよくあります。さらに、システムは、（現在）マルチコアマシンで実行されているさまざまなスレッド/プロセス間でコードページを共有することはできません。これは、仮想メモリなどの多くの利点を無効にします。また、ハードウェアレベルで行われたブランチ最適化を無効にします。

（注-私はJITを自己変更コードのカテゴリに含めていません。JITはコードの1つの表現から別の表現に変換しています。コードを変更するわけではありません）

全体として、それは単に悪い考えです-本当にきちんと、本当にあいまいですが、本当に悪いです。

もちろん-8080バイトと〜512バイトのメモリしかない場合は、そのような方法に頼らなければならない可能性があります。

オペレーティングシステムカーネルの観点から、すべてのJust In Time CompilerおよびLinker Runtimeはプログラムテキストの自己変更を実行します。顕著な例は、GoogleのV8 ECMAスクリプトインタープリターです。

自己変更コード（実際には「自己生成」コード）のもう1つの理由は、パフォーマンスのためにジャストインタイムコンパイルメカニズムを実装することです。たとえば、代数式を読み取り、一連の入力パラメータでそれを計算するプログラムは、計算を述べる前に式をマシンコードに変換する場合があります。

ハードとソフトウェアの間に論理的な違いがないという古い栗を知っています...コードとデータの間に論理的な違いがないとも言えます。

自己変更コードとは何ですか？値を実行ストリームに入れて、データではなくコマンドとして解釈できるようにするコード。もちろん、関数型言語には、実際には違いはないという理論的な見方があります。eは、命令型言語とコンパイラー/インタープリターで、同等のステータスであると推定せずに、これを簡単に行うことができると言っています。

私が言及しているのは、データがプログラムの実行パスを変更できるという実際的な意味です（ある意味でこれは非常に明白です）。私は、プログラムがコマンドからコマンドに移動するのと同じように、解析から状態への移動（および他の変数の変更）で移動するテーブル（データの配列）を作成するコンパイラーコンパイラーのようなものを考えています。 、プロセス内の変数を変更します。

したがって、コンパイラがコードスペースを作成し、完全に別個のデータスペース（ヒープ）を参照する通常の場合でも、データを変更して実行パスを明示的に変更できます。

進化を使用して最高のアルゴリズムを作成するプログラムを実装しました。自己変更コードを使用してDNA設計図を変更しました。

1つの使用例は、ウイルス対策プログラムをテストするための正規のDOS実行可能COMファイルであるEICARテストファイルです。

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

実行可能ファイルには、エンコード可能な命令の数を大幅に制限する[21h-60h、7Bh-7Dh]の範囲の印刷可能/入力可能なASCII文字のみを含める必要があるため、自己コード変更を使用する必要があります。

詳細はこちら

DOSでの浮動小数点演算ディスパッチにも使用されます

一部のコンパイラはCD xx、x87浮動小数点命令の代わりに0x34-0x3Bの範囲のxxで出力します。CDは命令のオペコードなのでint、x87コプロセッサが使用できない場合は、割り込み34h-3Bhにジャンプしてソフトウェアでその命令をエミュレートします。それ以外の場合、割り込みハンドラーはこれらの2バイトをに置き換える9B Dxため、後の実行はエミュレーションなしでx87によって直接処理されます。

MS-DOSでのx87浮動小数点エミュレーションのプロトコルは何ですか？

Linuxカーネルちょうどそれをロード可能なカーネルモジュールを持っています。

Emacsにもこの機能があり、私はいつもそれを使用しています。

動的プラグインアーキテクチャをサポートするものは、基本的に実行時にコードを変更します。

継続的に更新されるデータベースに対して統計分析を実行します。私の統計モデルは、使用可能になる新しいデータに対応するためにコードが実行されるたびに作成および再作成されます。

これが使用できるシナリオは学習プログラムです。ユーザー入力に応じて、プログラムは新しいアルゴリズムを学習します。

1. 同様のアルゴリズムの既存のコードベースを検索します
2. 同様のアルゴリズムがコードベースにない場合、プログラムは新しいアルゴリズムを追加するだけです
3. 同様のアルゴリズムが存在する場合、プログラムは（おそらくユーザーの助けを借りて）既存のアルゴリズムを変更して、古い目的と新しい目的の両方を提供できるようにします

Javaでそれを行う方法についての質問があります：Javaコードの自己修正の可能性は何ですか？

これの最良のバージョンはLispマクロかもしれません。単なるプリプロセッサであるCマクロとは異なり、Lispを使用すると、プログラミング言語全体にいつでもアクセスできます。これはlispの最も強力な機能であり、他の言語には存在しません。

私は決して専門家ではありませんが、Lispの人の1人に話してもらいます！彼らがLispが周りで最も強力な言語であり、賢い人々が彼らがおそらく正しいというわけではないと言うのには理由があります。