web-dev-qa-db-ja.com

libcに戻る-libcのアドレスの検索とオフセットの検索

したがって、 https://sploitfun.wordpress.com/2015/05/08/bypassing-nx-bit-using-return-to-libc/ に従って、libcへの戻りを実行してみました。

「ldd vuln」を使用してlibcのアドレスを見つけ、「readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system」を使用してシステムのオフセットを見つけました。

プログラムのfflushコマンドで「sh」のアドレスを見つけるのに苦労していました。

バイナリの16進ダンプを試しましたが、「sh\x00」のオフセットが見つかりましたが、バイナリのベースアドレスが見つかりませんでした。

私が見つけたlibcのアドレスとシステムのオフセットが有効かどうかはわかりません。また、「sh\x00」文字列の実際のアドレスを見つける方法がわかりません。

アドレスの検索方法が間違っている場合は修正してください。文字列のアドレスを検索する際のサポートが必要です:)

前もって感謝します！ :-)

exploitbuffer-overflowexploit-developmentdebuggingglibc
2
Jonathan

まず、問題に取り組む前に、実行可能ファイルがASLRで実行されているかどうかを確認する必要があります（ https://en.wikipedia.org/wiki/Address_space_layout_randomization ）その場合は、 libcのアドレスは毎回異なるため、プログラムからアドレスをリークする方法を見つけるため。これは、gdb-> b main-> info procマッピングを数回実行し、オフセットを比較することで簡単に確認できます。それらが異なる場合、実行可能ファイルはおそらくASLRで実行されています。 ASLR保護がないと仮定すると、gdb-> b main-> info procマッピングを使用すると、libc SOのベースアドレスが提供されます。ジャンプしたい関数のオフセットを見つけるには、多くの方法を使用できますが、readelf -sを使用すると正常に機能します。これにより、SO（SOのベースアドレス+オフセット=実行時のコードの位置）。

実行時に実行可能モジュールのベースアドレスを見つけるには、gdbまたは他のデバッガを使用して、実行可能ファイルのエントリポイントを検索します（または、実行可能ファイルがメモリにロードされた後で文字列を検索します...）。基本的に、実行可能ファイルをメモリにロードし、メモリを表示できるすべてのプログラムで実行できます。

Linuxでの実行可能ファイルのアドレスは、通常、64ビットの実行可能ファイルの場合は0x400000、32ビットの実行可能ファイルの場合は0x08048000です。これは、gnuリンカーで定義されています。しかし、エントリポイントを別のアドレスに変更することを妨げるものは何もありません。

メモリマッピングを理解したら、コード内でガジェットを見つける必要があります。調査するために残しておきます... https://en.wikipedia.org/wiki/Return -to-libc_attack

おそらく、exploit-exercises.comでエクササイズを見ることで、より多くの答えを見つけることができます。たとえば、protostar stack6はret2libcを処理する必要があります。ウォークスルーを探すことができます。

編集：lddが常に正しいアドレスを与えるとは限らないようです、私のシステムでASLRの無効化を無視します-おそらくgdbを使用する方が良いでしょう

2
lightnet

以下に2つのメソッドを示します。1. _strings -t x -a /path/to/libc | grep "/bin/sh"_-->これは、libc内の文字列のオフセットを出力します。
2。 pwntoolsで：最初にlibc = ELF（ '/ path/to/libc'）libc_binsh=libc.search("/bin/sh\x00").next()でlibcを定義します

1
Arav Garg