読者です 読者をやめる 読者になる 読者になる

ichirin2501's diary

いっちりーん。

C++のコードを逆アセンブリして遊ぶ

風邪完治かも!


アセンブリするC++コードはこれです。
環境は Linux ubuntu-vm 2.6.24-18-generic #1 SMP Wed May 28 20:27:26 UTC 2008 i686 GNU/Linux 
解析ツールは IDAPro, gdb

#include <iostream>
#include <string>
int main(){
	std::string s = std::string(4,'A');
	std::cout << s << std::endl;
	return 0;
}


C++のコードを初めて逆アセンブリしたとき、うわああああって思った。
原因は関数名が一見めちゃくちゃだったからだ。一応命名規則は存在していて、
丁寧に解析してくれるツールも存在してた。
nmコマンドでシンボル名を調べてくれる。オプションで解析もしてくれる。
以下のシンボル名は関係がありそうなものを抜き出してきたもの。

$ g++ hoge.cpp
$ nm a.out
08048980 t _Z41__static_initialization_and_destruction_0ii
         U _ZNKSs4sizeEv@@GLIBCXX_3.4
         U _ZNKSsixEj@@GLIBCXX_3.4
         U _ZNSaIcEC1Ev@@GLIBCXX_3.4
         U _ZNSaIcED1Ev@@GLIBCXX_3.4
         U _ZNSolsEPFRSoS_E@@GLIBCXX_3.4
         U _ZNSsC1EjcRKSaIcE@@GLIBCXX_3.4
         U _ZNSsD1Ev@@GLIBCXX_3.4
         U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
         U _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4
08048874 t _ZSt17__verify_groupingPKcjRKSs
08048ac6 W _ZSt3minIjERKT_S2_S2_
08049e80 B _ZSt4cout@@GLIBCXX_3.4
         U _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@@GLIBCXX_3.4
08049f10 b _ZSt8__ioinit
         U _ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E@@GLIBCXX_3.4


$ nm --demagle a.out
08048980 t __static_initialization_and_destruction_0(int, int)
         U std::string::size() const@@GLIBCXX_3.4
         U std::string::operator[](unsigned int) const@@GLIBCXX_3.4
         U std::allocator<char>::allocator()@@GLIBCXX_3.4
         U std::allocator<char>::~allocator()@@GLIBCXX_3.4
         U std::ostream::operator<<(std::ostream& (*)(std::ostream&))@@GLIBCXX_3.4
         U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(unsigned int, char, std::allocator<char> const&)@@GLIBCXX_3.4
         U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@@GLIBCXX_3.4
         U std::ios_base::Init::Init()@@GLIBCXX_3.4
         U std::ios_base::Init::~Init()@@GLIBCXX_3.4
08048874 t std::__verify_grouping(char const*, unsigned int, std::string const&)
08048ac6 W unsigned int const& std::min<unsigned int>(unsigned int const&, unsigned int const&)
08049e80 B std::cout@@GLIBCXX_3.4
         U std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)@@GLIBCXX_3.4
08049f10 b std::__ioinit
         U std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char>, std::allocator<char> >(std::basic_ostream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@@GLIBCXX_3.4

ざっと見ていきましょう。

.text:0804837E                 lea     eax, [ebp+var_9]
.text:08048381                 mov     [esp+40h+var_40], eax
.text:08048384                 call    _ZNSaIcEC1Ev
.text:08048389                 lea     eax, [ebp+var_9]
.text:0804838C                 mov     [esp+40h+var_34], eax
.text:08048390                 mov     [esp+40h+var_38], 41h
.text:08048398                 mov     [esp+40h+var_3C], 4
.text:080483A0                 lea     eax, [ebp+var_10]
.text:080483A3                 mov     [esp+40h+var_40], eax
.text:080483A6                 call    _ZNSsC1EjcRKSaIcE
.text:080483AB                 lea     eax, [ebp+var_9]
.text:080483AE                 mov     [esp+40h+var_40], eax
.text:080483B1                 call    _ZNSaIcED1Ev

_ZNSaIcEC1Ev
	std::allocator<char>::allocator()
_ZNSsC1EjcRKSaIcE
	std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(unsigned int, char, std::allocator<char> const&)
_ZNSaIcED1Ev
	std::allocator<char>::~allocator()

stringって実はbasic_stringのtypedef らしい。
さてと、順を追っていくと、
[ebp+var_9]のアドレスにデフォルトのallocatorをセット?して、第3引数としてスタックに積む。
0x41('A')を第2引数としてスタックに積んで、第1引数に個数である4をスタックに積んでいる。
でも、よく見てみると、さらに[ebp+var_10]のアドレスがスタックに積まれている。これはstring型変数sを指している。
次の処理としてallocatorをデコンストラクタしている。
allocatorの扱いがよくわかんないww

.text:080483B6                 lea     eax, [ebp+var_10]
.text:080483B9                 mov     [esp+40h+var_3C], eax
.text:080483BD                 mov     [esp+40h+var_40], offset _ZSt4cout
.text:080483C4                 call    _ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E
.text:080483C9                 mov     [ebp+var_1C], eax
.text:080483CC                 jmp     short loc_80483ED

_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E
	std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char>, std::allocator<char> >(std::basic_ostream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&
長すぎwww

operator<<にstd::coutと文字列'AAAA'のアドレスを渡している。少し脱線するが、

#include <iostream>
int main(){
	std::operator<< (std::cout,"AAAA");
	return 0;
}

みたいにも書けるらしい。

気になったのは、callした後、eaxレジスタの内容を[ebp+var_1C]に格納していること。
operator処理を行う前のeaxレジスタには文字列'AAAA'を指すアドレスが格納されているはずだが、
callを呼んだあとにも同じ値が入ってるのか?…
eaxレジスタは関数の返り値を格納する役割もある。でも、std::coutって返り値あったっけ?
と思ったのがこの記事を書く発端である。調べる過程で、デマングルの存在を知った。
(以前に@ucq氏、@a4lg氏に助言を戴いたことをすっかり失念していたorz)
ので、自分が行ったことと記事の順序が少々前後していて、既に上記の記述の中に答えは出ているが…w
gdbで動的解析してみる。

--------0x08048a3d-------
cout前のeaxレジスタを確認
アドレス値が0bfxxxxxxなので、ユーザスタック領域を指している。どうでもいいw
(gdb) i r
eax            0xbf9f4f08	-1080078584
ecx            0x0	0
edx            0xbf9f4f08	-1080078584
ebx            0xb7e66ff4	-1209634828
esp            0xbf9f4ee0	0xbf9f4ee0
ebp            0xbf9f4f18	0xbf9f4f18
esi            0xb7fb8ce0	-1208251168
edi            0x0	0
eip            0x8048a3d	0x8048a3d <main+77>
eflags         0x246	[ PF ZF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

--------0x08048a4d-------
cout後のeaxレジスタを確認(ただし、endlはまだ呼ばれてない状態)
(gdb) i r
eax            0x8049e80	134520448
ecx            0xb7f8672c	-1208457428
edx            0x4	4
ebx            0xb7e66ff4	-1209634828
esp            0xbf9f4ee0	0xbf9f4ee0
ebp            0xbf9f4f18	0xbf9f4f18
esi            0xb7fb8ce0	-1208251168
edi            0x0	0
eip            0x8048a4d	0x8048a4d <main+93>
eflags         0x286	[ PF SF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

少し脱線して、cout前のeaxレジスタは何を指していたのかを確認。

(gdb) x/8x 0xbf9f4f08
0xbf9f4f08:	0x0804a014	0x08048b19	0xbf9f4f30	0xb7e66ff4
0xbf9f4f18:	0xbf9f4f88	0xb7d32450	0xb7fb8ce0	0x08048b00
(gdb) x/8x 0x0804a014
0x804a014:	0x41414141	0x00000000	0x00020fe9	0x00000000
0x804a024:	0x00000000	0x00000000	0x00000000	0x00000000

というわけで、eaxレジスタには文字列'AAAA'のアドレスを指すアドレスが格納されてました。
ちなみに、0x0804a000以降はヒープ領域です。確認方法は、プログラム動作中に cat /proc/pid_number/smaps で確認。

0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
Size:                132 kB
Rss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB

話を戻しましょう。
cout後のeaxレジスタには 0x8049e80 が格納されてましたが、このアドレスが一体何を指してるのか確認。

(gdb) x/8x 0x8049e80
0x8049e80 <_ZSt4cout@@GLIBCXX_3.4>:	0xb7f8672c	0xb7f86740	0x00000006	0x00000000
0x8049e90 <_ZSt4cout@@GLIBCXX_3.4+16>:	0x00001002	0x00000000	0x00000000	0x00000000

静的解析ではさっぱりわかりませんでしたが、std::coutのアドレスが格納されてるアドレスを指していたようです。

(gdb) x/8x 0xb7f8672c
0xb7f8672c <_ZTVSo+12>:	0xb7f24ad0	0xb7f248f0	0xfffffffc	0xfffffffc
0xb7f8673c <_ZTVSo+28>:	0xb7f86768	0xb7f24ac0	0xb7f248e0	0xb7f8672c
さらに指してるアドレスを見たところ、 _ZTVSo が気になったので調べてみた。
動的リンクでコンパイルするとそれらしい名前は発見できなかったので、静的リンクでコンパイルしてみたところ、見つけることができた。
$ g++ -static hoge.cpp
$ nm a.out | grep ZTVSo
08107220 V _ZTVSo
$ nm --demangle a.out | grep 08107220
08107220 V vtable for std::ostream

うーん…軽くぐぐったが、奥が深そうなので今はスルーしておこう。脱線してるしw


静的リンクでコンパイルして、std::endlの部分を見てみた。

_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
.text:0806F950                 push    ebp
.text:0806F951                 mov     ebp, esp
.text:0806F953                 push    ebx
.text:0806F954                 sub     esp, 14h
.text:0806F957                 mov     ebx, [ebp+arg_0]
.text:0806F95A                 mov     [esp+18h+var_14], 0Ah
.text:0806F962                 mov     eax, [ebx]
.text:0806F964                 mov     edx, [eax-0Ch]
.text:0806F967                 lea     eax, [ebx+edx]
.text:0806F96A                 mov     [esp+18h+var_18], eax
.text:0806F96D                 call    _ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc
.text:0806F972                 mov     [esp+18h+var_18], ebx
.text:0806F975                 movsx   eax, al
.text:0806F978                 mov     [esp+18h+var_14], eax
.text:0806F97C                 call    _ZNSo3putEc
.text:0806F981                 mov     [ebp+arg_0], eax
.text:0806F984                 add     esp, 14h
.text:0806F987                 pop     ebx
.text:0806F988                 pop     ebp
.text:0806F989                 jmp     _ZNSo5flushEv

_ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc
	std::basic_ios<char, std::char_traits<char> >::widen(char) const
_ZNSo3putEc
	std::ostream::put(char)
_ZNSo5flushEv
	std::ostream::flush()

0Ahの文字が見えるから改行って感じするけど、flushも呼んでるっぽい。

一番気になってた _ZNSolsEPFRSoS_E(std::ostream::operator<<(std::ostream& (*)(std::ostream&))) を覗いてみたら、

.text:0806D480                 push    ebp
.text:0806D481                 mov     ebp, esp
.text:0806D483                 mov     ecx, [ebp+arg_4]
.text:0806D486                 pop     ebp
.text:0806D487                 jmp     ecx

しょぼすぎて唖然としたw

_ZNSolsEPFRSoS_Eが呼ばれるの手前

.text:080483ED                 mov     [esp+40h+var_3C], offset _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
.text:080483F5                 mov     eax, [ebp+var_1C]
.text:080483F8                 mov     [esp+40h+var_40], eax
.text:080483FB                 call    _ZNSolsEPFRSoS_E

これを見ると、第1引数にstd::cout、第2引数にstd::endlがスタックに積まれて渡されてる。
なので、_ZNSolsEPFRSoS_Eの処理はarg_4は第2引数を指しているため、std::endlにjmpしてるだけ?いらなくね?…
一応動的解析のほうでも確認しておく。

(gdb) si
0x0806d480 in std::ostream::operator<< ()
Current language:  auto; currently asm
(gdb) i r
eax            0x8140a00	135531008
ecx            0x810722c	135295532
edx            0x4	4
ebx            0x0	0
esp            0xbfe3415c	0xbfe3415c
ebp            0xbfe34198	0xbfe34198
esi            0x20618	132632
edi            0x3	3
eip            0x806d480	0x806d480 <std::ostream::operator<<(std::ostream& (*)(std::ostream&))>
eflags         0x382	[ SF TF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

(gdb) x/8x $esp
0xbfe3415c:	0x08048400	0x08140a00	0x0806f950	0x00000041
0xbfe3416c:	0xbfe3418f	0x08121968	0x0814016c	0xbfe34188
(gdb) x/4x 0x08048400
0x8048400 <main+148>:	0x000000bb	0xf0458d00	0xe8240489	0x0002d540
(gdb) x/4x 0x08140a00
0x8140a00 <_ZSt4cout>:	0x0810722c	0x08107240	0x00000006	0x00000000
(gdb) x/4x 0x0806f950
0x806f950 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_>:	0x53e58955	0x8b14ec83	0x44c7085d	0x000a0424


.text:0806D483                 mov     ecx, [ebp+arg_4]
の処理が終わった後のレジスタの状態を見てみる。
(gdb) si
0x0806d486 in std::ostream::operator<< ()
(gdb) i r
eax            0x8140a00	135531008
ecx            0x806f950	134674768
edx            0x4	4
ebx            0x0	0
esp            0xbfe34158	0xbfe34158
ebp            0xbfe34158	0xbfe34158
esi            0x20618	132632
edi            0x3	3
eip            0x806d486	0x806d486 <std::ostream::operator<<(std::ostream& (*)(std::ostream&))+6>
eflags         0x382	[ SF TF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

引数arg_4の値を代入されたecxレジスタを確認してみると、0x806f950 が格納されている。
これは先ほどの確認した std::endl を指すアドレスと一致。まぁ、当然…。

.text:0806D486                 pop     ebp
の処理が終わった後のレジスタの状態
(gdb) si
0x0806d487 in std::ostream::operator<< ()
(gdb) i r
eax            0x8140a00	135531008
ecx            0x806f950	134674768
edx            0x4	4
ebx            0x0	0
esp            0xbfe3415c	0xbfe3415c
ebp            0xbfe34198	0xbfe34198
esi            0x20618	132632
edi            0x3	3
eip            0x806d487	0x806d487 <std::ostream::operator<<(std::ostream& (*)(std::ostream&))+7>
eflags         0x382	[ SF TF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

ベースポインタを元に戻して、std::endl処理にjmpと。何をしにきたんだって言いたくなるw


2011/1/31 15:02 追記:
ところどころアセンブリのアドレス値がおかしいのは動的リンク時のコードと静的リンク時のコードが混在してるから…っぽい。
申し訳ないorz