私の問題は非常に似ていますが、これと同じではありません。
私は、本の中で exploite_notesearch.c の同じ例を実行しました: Hacking, the Art of Exploitation on my 64-bit OS, Archlinux で動作しません。
上記のリンクから、ほとんどの 64 ビット システムでは動作しないことがわかりました。しかし、プログラムがこれを行う必要がある理由をまだ理解できません: ret = (unsigned int)&i - offset. ret = (unsigned)shellcode脆弱なプログラムの戻りアドレスをシェルコードの開始アドレスに置き換えるために、これを行うことができないのはなぜですか?
は、プログラム内のシェルコード配列のアドレスret = (unsigned)shellcodeにret等しくなります。しかし、そのアドレスは、ターゲット プログラム内の悪意のあるコードのアドレスではありません ( notesearch.c)。ターゲット プロセスがsearchstringスタックに配置されるため、悪意のあるコードもターゲット プロセスのスタックに配置されます。
昔は、プロセスのメモリ レイアウトは通常、非常に決定論的でした。通常、スタック バッファの場所は、攻撃者によってかなり正確に予測できました (特に、攻撃対象のソフトウェアのバージョンが正確にわかっている場合)。したがって、シェルコードの正確なアドレスが何であるかを知るのは非常に簡単searchstringです。
ただし、今日では、多くのオペレーティング システムが ASLR を実行します。そのため、スタックに挿入されたシェルコードを実行しようとする攻撃者は、最初にスタックを見つける必要があります。システムは、関連するメモリ アドレスを攻撃者から隠します。これらの値は推測する必要があり、誤った推測は通常、アプリケーションのクラッシュ (セグメンテーション フォールト) により回復できません。
当て推量が含まれている場合に成功の可能性を高めるために、アクティブなシェルコードの前に、「NOP スレッド」または「NOP スライド」と呼ばれる、有用な操作を実行しない大量の実行可能なマシン コードが先行することがよくありました。
そのret = (unsigned int)&i - offsetため、シェルコードが正常に実行されることを確認できません。