Gdbでバイナリファイルをデバッグしています。 Intel IA-32でgccによってコンパイルされたCコードでした。この出力をobjdump
から取得しました。私はここの最後の行に最も興味があります:
08048d9e <func_1>
8048d9e: 55 Push %ebp
8048d9f: 89 e5 mov %esp,%ebp
8048da1: 83 ec 18 sub $0x18,%esp
8048da4: c7 44 24 04 88 99 04 movl $0x8049988,0x4(%esp)
8048dab: 08
8048dac: 8b 45 08 mov 0x8(%ebp),%eax
8048daf: 89 04 24 mov %eax,(%esp)
8048db2: e8 54 01 00 00 call 8048f0b <strings_not_equal>
この最後の行は、示されたアドレスで見つかった値を比較すると思います:8048f0b
。私は試みます:
(gdb) x 0x8048f0b
そして受け取る:
0x8048f0b <strings_not_equal>: 0x57e58955
アセンブリを誤って解釈していますか?これはgdbのアドレスの値を読み取る正しい方法ですか?私は、よりアスキーフレンドリーな16進値を見つけることを期待していました。比較する保存された文字列値を見つけることに興味があります。
また、このタイプのデバッグに使用したいお気に入りのGUIツールはありますか?私はdddを試すことを考えてきました。より簡単なデバッグ方法を見つけたいです。
メモリアドレス_0x8048f0b
_の値を正しく読み取っていますが、_call 8048f0b <strings_not_equal>
_行は、このアドレスが関数(strings_not_equal()
と呼ばれる)の開始であることを示しています。 ASCII-より多くのマシンコードになると期待するでしょう。
strings_not_equal()
の関数引数を探している場合、それらはスタックにプッシュされています。最初の引数は、0x8(%ebp)
の最初の引数であるfunc1()
からコピーされています。 2番目の引数は_$0x8049988
_で、おそらく文字列のアドレスです。
アドレスの内容を文字列として印刷する場合は、_x/s
_を使用して印刷できます。
_x/s 0x8049988
_