背景: IP パケット、特にパケットのペイロード/データを検査して、バッファ (スタック) オーバーフローで使用できるかどうかを検出するための Python スクリプトを作成しました。NOP スレッドを使用してスタックをパディングし、最終的に命令ポインターがエクスプロイト コードに実行されるようになっていることがわかりました。これは、0x90 の繰り返し発生を探すことで簡単に検出できます。SQL スラマーの場合、多くの NOP コマンドを 8 つまで使用するコードを見たことがあります。
さて、私の質問ですが、NOP スレッドは正当なコードでよく使用されますか? 答えが「はい」の場合、特定のケースがいくつかあるのでしょうか (つまり、これらのケースを探して、無害である可能性があるパケットを除外できるということです)、それともこのアプローチは、悪意のあるコードを特定するのに実際的ではないのでしょうか?
コンパイラは、コードを整列するために NOP を生成します。たとえば、x86 の一部の反復では、ジャンプ先が 4、8、または 16 バイトの境界に整列されている場合、ジャンプの実行が高速になります。
一部のコンパイラは、可能であれば「長い NOP」を使用しようとします。これは、1 バイト以上のスペースを占有し、正式には何かを実行する可能性がありますが、プロセッサの状態には影響を与えない単一の命令です。x86 アーキテクチャの一部の反復では、これはもっと早く。たとえば、66 90は 2 バイトの NOP であり、8d 74 26 00は 4 バイトの NOP です (技術的lea 0(%esi,%eiz,1),%esiには ですが、ご覧のとおり、値%esiをそれ自体にコピーするだけなので、効果はありません)。ただし、これらはすべての場合に使用できるわけではなく、一部の x86es で最速のシーケンスが、他の x86es では気が滅入るほど遅いことがよくあります。私は現在のマイクロ最適化ガイドラインを読んでいませんが、Intel と AMD が一連の90これは、長い NOP を実行する最速の方法であり、コンパイラが一致していました。
ウィキペディアから：
NOP は、最も一般的にはタイミングの目的で使用され、メモリ アライメントを強制し、ハザードを防止し、分岐遅延スロットを占有し、またはプログラム開発の後でアクティブな命令に置き換えられるプレースホルダーとして (または削除された命令を置き換えるために) 使用されます。リファクタリングは問題があったり、時間がかかったりします)。場合によっては、NOP に軽微な副作用が生じることがあります。たとえば、Motorola 68000 シリーズのプロセッサでは、NOP オペコードがパイプラインの同期を引き起こします。
さらに、0x90初期化されていない配列のフィラーとしてコンパイラによって使用される可能性があります。配列内のデータがオペコードとして解釈された場合、何もしません。0xCCVisual Studio で同様の効果が見られます。これは初期化されていない配列を埋めint 3、ブレークポイントの停止を引き起こします。
さらに、実行可能ファイル内のデータには任意の数の が含まれている可能性があり0x90、それとコードを区別するのは簡単ではない場合があります。
コンパイルした最後のバイナリ (Linux 上の悪意のない x86 コード) を調べたところ、次のことがわかりました。
016b5e0 458b c9ec 90c3 9090 9090 9090 9090 9090
0x90 の繰り返しシーケンスを見つけても、必ずしも悪意があるとは限らないと結論付けることができると思います。