このチュートリアル ( https://www.youtube.com/watch?v=8xonDJe3YxI ) に従って、サーバー ( -m32 フラグを使用してコンパイル) を arch linux x86_64 マシンで実行しています。
すべて問題ありませんが、コア ダンプ ファイルを開くと、アプリケーションを実行するたびにアドレスが変更
gdbされていることがわかります...esp
なぜesp住所が変わるのですか？
チュートリアルを続けるためにこれを処理するにはどうすればよいですか?
残念ながら、x64 での単純なエクスプロイトのようなものは存在しない可能性が十分にあります。ASLR など、既に遭遇した他の問題の中で、NX ビットがすべての x64 対応プロセッサの機能であるという事実にも満足する必要があります。
お使いの CPU が NX をサポートしているかどうかを確認するには: cat /proc/cpuinfo | grep "nx". フラグで強調表示されている場合nxは、NX ビットがあり、カーネルがおそらくそれを使用しています。
NX-bit は、ハードウェアでサポートされている方法であり (技術的には、カーネルが実行すべきでないページを示します)、「ここのメモリのこの領域は、絶対に実行しないでください」と言います。これは、挿入されたあらゆる種類のシェルコードをうまく打ち負かすため、一般的にスタックに適用されます。スタック ベースのエクスプロイトは、必要な場所へのジャンプを上書きする可能性があります。つまり、nullfree コードで挿入したばかりのバッファーです。ただし、eip/rip をそこに移動する代わりに、プロセッサが障害を発生させるようになりました。
これをオフにすることはできますが、このフラグは ELF の一部であるため、プロセスごとに行う必要があります。これを行うexecstackには、実行可能スタックのステータスも照会できるユーティリティを使用します。
でこのポスト ビルドを行うこともできますgcc -z execstack。
お気づきのとおり、これは一般的な現実世界のシナリオではありません。execstack で実行されている Linux 上のバイナリがあります (Nvidia グラフィックス コンポーネントは 1 つだと思います) が、それらはまれです。
私が理解しているように、あなたはASLRを管理しましたが、これを読む可能性のある他の人のために、次の方法でオフにすることができます:
echo 0 > /proc/sys/kernel/randomize_va_space
ルートとして。
実行不可能なスタック (ASLR によって妨げられる可能性がある) を回避する方法は、リターン指向プログラミングを使用することです。非常に簡単な概要: スタックを上書きできるため、C 標準ライブラリなどの既知の関数のスタック フレーム (または一連のスタック フレーム) のように見えるスタックを作成できます。これらを使用すると、libc 関数を実行できます。これは、達成できる点で非常に強力です。ただし、libc に限定されるわけではありません。
これに関する Windows 向けのチュートリアルは、こちらから入手できます。