環境変数のアドレス確認方法について GDB

Question

シェルコードを環境変数に登録しました。
（動くかはわからない）

今気づいたけど0があるからシェルコードとしては使えない・・・
ただ、今回は話が違うので・・・

シェルコードが置かれている環境変数のアドレスを確認します。

$gdb ./test

$break main

$run

$x/24s $rsp + 900

すると

なんで、16進数表記のアドレスが6バイトで表示されているのでしょうか？
ふつう、4バイトですよね？

int main(void){
printf("%p\n",getenv("SHELLCODE"));
return 0;
}

それで、実行するとこちらも6バイトで表示されます。

なぜでしょうか？

分からないのでお願いします。

Answer 1

64bitのOSとコンパイラなのでは？
上の2byte分は0なので、表示してないだけのように思えます。

Comments

[退会済みユーザー]

補足です。アーキテクチャの記載がないので推測ですが、amd64だと仮定します。
https://ja.wikipedia.org/wiki/X64#AMD64 にあるとおり、
「AMD64アーキテクチャでは、現状の実装で48ビットのアドレス空間を持ち、256テラバイトまでのメモリを扱うことが出来る」から
です。
正確には物理アドレスとは違うマッピングがプロセスごとにされているので、違うけど、大まかにはそういうことになります。
回答者さんのおっしゃるとおり、48bitより上の部分はたとえレジスタが64bitでも意味を持ちません。

[kazuyakazuya]

回答ありがとうございます。

64ビット windows　上で仮想環境を築き

64ビット CentOS

を使っています。

つまり、x24/s $rsp + 900

というコマンド自体が

32ビットOSを前提にしたものあから

アドレスの表示がおかしいことになっているということですか？

[maisumakun]

> 32ビットOSを前提にしたものあからアドレスの表示がおかしいことになっているということですか？

いえ、違います。32ビットならメモリ空間は4GBしかないので、32ビットしか出ません。

[kazuyakazuya]

私が普段見てきた4バイト表示に
することはできないのでしょうか？
（今回表示されたアドレス

0x7FFFFFFFe7 ならば

ひだりの7FFF

2バイトは無視したら4バイトになりますが・・・）

[maisumakun]

> 私が普段見てきた4バイト表示にすることはできないのでしょうか？

なんのためにでしょうか。アドレス空間は48ビットなので、勝手に削っては辻褄が合いません。

[dodox86]

> つまり、x24/s $rsp + 900
> というコマンド自体が
> 32ビットOSを前提にしたものあから

なぜそう言う解釈になるのかｗ　全然違います。

そもそも、$rspが64ビット用のスタックポインターです。この時点でもう意識は64ビットOS用です。次に、dameoさんのコメントをいたただいたように、
> AMD64アーキテクチャでは、現状の実装で48ビットのアドレス空間を持ち、
とあり、48ビットつまり6バイトです。64ビットOSとは言え、ハードウェアとして48ビット(=6バイト)しかアドレス空間を使わないので、gdbでも6バイトしか表示しない（上位2バイトは意味が無い）のです。

[退会済みユーザー]

はい、というわけで、細かい解説書きました。

ちゃんとお答えするとすると、64bit CentOSは32bit動作するものと64bit動作するプログラムの両方を動かせます。

64bit動作するプログラムを動かすと、アドレス表示は48bit=6バイトになり
32bit動作するプログラムを動かすと、アドレス表示は32bit=4バイトになります

xコマンドはいわゆるメモリダンプコマンドです。
後ろで指定されたアドレスからダンプしてくれます。

x/24sはさらに、24個分メモリを文字列形式としてダンプしてくれって意味になります。
$rsp+900がアドレス指定です。
$rspはRSPレジスタの中身です。gdb的にはvoid*として扱われます。

つまりRSPから900先のアドレスを文字列形式で24個ダンプしてって言うコマンドです。
そのダンプしたときのアドレス表示が
64bitプログラムなら6バイト
32bitプログラムなら4バイト
ってことです。

[退会済みユーザー]

※32bitプログラムのときは$rspではなくて、$spにしてください。

[kazuyakazuya]

ありがとうございます。

Visual stdio

で、printf("%p")

これでアドレスを表示させていたときは

4バイトで表示されたのは

32ビットで設定されていたから？

では、バッファオーバーフローでリターンアドレスを書き換えるとき

先頭の2バイトは考慮せずに問題ないでしょうか？

[退会済みユーザー]

今の話はadm64のCentOS環境でgdbの出力がどうなるかという話なので、他のOSの他の処理系で、しかもデバッガの出力でもないものと比較は出来ません。
全く別の話です。

そしてバッファオーバーフローでリターンアドレスを書き換えるというのは、そもそもどちらとも関連がないです。

[kazuyakazuya]

確かに関係ありませんでした。すみません。

もう一度調べなおします。

[asm]

centos上の環境変数を書き換えたところで、windows上から読めないのと同様に
32bitのアドレスを入手したところで、攻撃対象の実行ファイルが64bitでは意味が(ほぼ)ないです。
(推測が不可能か？と言われると困るけど、普通に攻撃対象と同種の実行ファイルでアドレスを入手した方が簡単)

[kazuyakazuya]

おそらく、アドレスに対して間違った認識のままここまで

来たのだと思います・・・。

まず、Visual Stdioでは

X86,X64を選べるそうですが

CPUがX86のアーキテクチャで、VisualでX64を選択した場合

アドレスが48ビットではなく、32ビットになるもんなんですか？
（仮想マシンではできるみたいですが・・・）

もし、そうだとしたら

CPU OS問わず、アドレスは4バイトだと固定だと勘違いしていました。

[maisumakun]

> CPUがX86のアーキテクチャで、VisualでX64を選択した場合

動きません。

[dodox86]

そういった一連のことの判断がつくようになることがkazuyakazuyaさんにとって最初に必要なのでは、と言う回答が、以下でいただいたものであったはずです。https://teratail.com/questions/219568
この質問も、（少なくとも私から見れば）PingHermitさんの回答と、その後の皆さんのコメントで充分過ぎるほどの回答になっていると思います。
（横からですみません）

[dodox86]

> この質問も、（少なくとも私から見れば）
あくまで質問主はkazuyakazuyaさんなので、少々出過ぎた意見で失礼しました。（回答に納得いくか否かは質問主が判断すべきこと、と言う意味で）

[kazuyakazuya]

Visual Stdioで～という話は

%pで表示させると、上のアドレスが省略されて表示されるみたいなので

本来６バイト長であるアドレスが4バイトに見えていただけのようです。

もしくは、32ビットとしてコンパイルしていたか？（らしいです。）

ありがとうございました。

[kazuyakazuya]

あ、分かったつもりでいましたが違がかったみたいです。

32ビットプロセスなら32ビット長アドレスになる。
（32,64ビットOS 32,64ビットCPUで実行可能 ）

64ビットプロセスなら48ビット長アドレスになる。
（64ビットCPU 64ビットOSでのみ実行可能）

どうやってアドレス長が決まるかは

CPU や OSではなく、プロセスで決まる

上のコメントの時点ではCPU OSで

アドレス長が決まると思っていました。

[asm]

ちなみに、アドレスバスの幅は48bitですが64bitプロセス(AMD64)の場合
機械語を含む多くの言語ではポインタ型の変数は64bitです。
printf("%d", sizeof(void*));
等で確かめられるかと思います。

[kazuyakazuya]

ありがとうございます。

それはデータバス幅がアドレスバスとは違い

64ビットとなっているからでしょうか？

[kazuyakazuya]

あ、いやなんでもないです。

勘違いです。