https://qiita.com/howmuch515/items/b86f7341c574edcbc717#war
こちらに上級者によるWriteupがあるので私が書くまでもないのですが…picoCTFのこの問題で手こずる初心者(=私)にはわかりにくいところがあるので説明をメモします
調査
まず問題文に”Connect on shell2017.picoctf.com:15646.”とありますがpicoCTFのサイトで用意されているシェルではtelnetコマンドが使えないのでncコマンドを使います。ncコマンドは多分どこでも使えるので、ncコマンドを使うのが普通みたいです
で、ちょっとプレイすると勝てないらしいことがわかります。
ソースコードを見ると、プレイヤーが勝った場合に表示する文に「あれ？勝った？おかしいな…」旨の文章が書いてあり、勝てないように作ってあることがわかります。
ゲーム自体は、26枚のカードデッキが2人のプレイヤー(コンピュータと人間)に作られ、それのマーク(suit)と数字を比較し、強い方が勝ち…で、26枚全て使い切ると終わりということになっています。使い切ったらカードスイッチング(?)をする予定だが未実装、という表示が出ます。
26枚のデッキ2組は、毎回固定値で生成され、乱数でシャッフルするのですが、コンピュータ側のデッキはどのカードも人間プレイヤーのカードより強くなるように生成されているので絶対に勝てません。
構造体の中身
ここで、gamestate構造体の中身は、「人間プレイヤーのカード配列、char型name配列、deckSize変数、コンピュータプレイヤーのカード配列」の順に並んでいます。
name配列に値を受け取るときに使われるreadInput関数は、末尾のインデックス+1に’ x00′ (=null)を格納してしまうというバグ持ちです。本来は末尾のインデックス+0に’ x00’を格納すべきです。
よって、name配列の長さ32文字を入力すると、name配列の範囲+1バイト、つまりとなりのdeckSize変数に1バイトぶん’ x00’を書き込んでしまうことになります。
(しかし、deckSize変数はsize_t型であり、32bit環境では4バイト、64bit環境では8バイトにだいたいなるはずです。なぜ1バイトぶん、deckSize変数に0を書き込むとdeckSizeが0になってしまうかというと、メモリ上のバイト列の並び方がリトルエンディアンだからです。要は下位1バイトを全部0にしているというわけです。deckSize変数に入れられた値が26でなく下位1バイトで表現しきれないほどもっともっと大きかった場合、下位1バイトを0にしただけじゃdeckSizeは0になってくれません。)
勝負がついたかどうかの判定
そして、残りデッキ枚数判定は、deckSizeをデクリメントして更新したあとに行われ、deckSizeが0と等しいかどうかで判定しています。deckSizeの初期値(正規には26)を不正に0にした場合、デクリメントにより負の値となってしまうのでこの判定をすり抜けてしまい、カードが無いのに勝負が続きます。
勝負がカードの枚数より多く繰り返された場合
一つのdeck構造体につきカード配列はなぜか52枚用意されます。
なので52回より多く勝負をすると、
人間プレイヤーの場合は、人間プレイヤーのカードの配列の次に並んでいる、name配列を読み込んでしまいます。コンピュータプレイヤーなら…0を読んでいます。(初期値なしグローバル変数として宣言されているからBSSセクションに配置されるから？そんでそのBSSセクションのあとはヒープ領域まで何もないっぽくて(参考:http://th0x4c.github.io/blog/2012/10/10/os-virtual-memory-map/)ずっと0が並んでるっぽいからみたい？メモリマップは以下のようにして確認できます。)
$ cat /proc/3812/maps 00400000-00402000 r-xp 00000000 fc:00 320292 /home/user1/デスクトップ/a.out 00601000-00602000 r--p 00001000 fc:00 320292 /home/user1/デスクトップ/a.out 00602000-00603000 rw-p 00002000 fc:00 320292 /home/user1/デスクトップ/a.out 01e80000-01ea1000 rw-p 00000000 00:00 0 [heap] 7fbb358c5000-7fbb35a85000 r-xp 00000000 fc:00 523255 /lib/x86_64-linux-gnu/libc-2.23.so 7fbb35a85000-7fbb35c85000 ---p 001c0000 fc:00 523255 /lib/x86_64-linux-gnu/libc-2.23.so 7fbb35c85000-7fbb35c89000 r--p 001c0000 fc:00 523255 /lib/x86_64-linux-gnu/libc-2.23.so 7fbb35c89000-7fbb35c8b000 rw-p 001c4000 fc:00 523255 /lib/x86_64-linux-gnu/libc-2.23.so 7fbb35c8b000-7fbb35c8f000 rw-p 00000000 00:00 0 7fbb35c8f000-7fbb35cb5000 r-xp 00000000 fc:00 523253 /lib/x86_64-linux-gnu/ld-2.23.so 7fbb35e93000-7fbb35e96000 rw-p 00000000 00:00 0 7fbb35eb4000-7fbb35eb5000 r--p 00025000 fc:00 523253 /lib/x86_64-linux-gnu/ld-2.23.so 7fbb35eb5000-7fbb35eb6000 rw-p 00026000 fc:00 523253 /lib/x86_64-linux-gnu/ld-2.23.so 7fbb35eb6000-7fbb35eb7000 rw-p 00000000 00:00 0 7ffdf2771000-7ffdf2792000 rw-p 00000000 00:00 0 [stack] 7ffdf2793000-7ffdf2795000 r--p 00000000 00:00 0 [vvar] 7ffdf2795000-7ffdf2797000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
と
$ size --format=SysV -x a.out a.out : section size addr .interp 0x1c 0x400238 .note.ABI-tag 0x20 0x400254 .note.gnu.build-id 0x24 0x400274 .gnu.hash 0x24 0x400298 .dynsym 0x198 0x4002c0 .dynstr 0x8c 0x400458 .gnu.version 0x22 0x4004e4 .gnu.version_r 0x20 0x400508 .rela.dyn 0x30 0x400528 .rela.plt 0x150 0x400558 .init 0x1a 0x4006a8 .plt 0xf0 0x4006d0 .plt.got 0x8 0x4007c0 .text 0x7d2 0x4007d0 .fini 0x9 0x400fa4 .rodata 0x32c 0x400fb0 .eh_frame_hdr 0x54 0x4012dc .eh_frame 0x174 0x401330 .init_array 0x8 0x601e10 .fini_array 0x8 0x601e18 .jcr 0x8 0x601e20 .dynamic 0x1d0 0x601e28 .got 0x8 0x601ff8 .got.plt 0x88 0x602000 .data 0x10 0x602088 .bss 0x150 0x6020a0 .comment 0x34 0x0 Total 0x1657
実際にメモリのダンプをして見ると
$ gdb a.out (gdb) run ...(省略)... (gdb) x/200xb 0x6020a0 0x6020a0 <stdout@@GLIBC_2.2.5>: 0x20 0x26 0xdd 0xf7 0xff 0x7f 0x00 0x00 0x6020a8 <completed.7585>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020b0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020c0 <gameData>: 0x64 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020c8 <gameData+8>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020d0 <gameData+16>: 0x1a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020d8 <gameData+24>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6020e0 <gameData+32>: 0x00 0x06 0x01 0x03 0x00 0x05 0x03 0x03 0x6020e8 <gameData+40>: 0x01 0x08 0x02 0x02 0x01 0x05 0x00 0x04 0x6020f0 <gameData+48>: 0x02 0x05 0x00 0x07 0x01 0x06 0x02 0x07 0x6020f8 <gameData+56>: 0x02 0x03 0x01 0x07 0x03 0x07 0x02 0x04 0x602100 <gameData+64>: 0x01 0x04 0x00 0x03 0x00 0x08 0x00 0x02 0x602108 <gameData+72>: 0x01 0x02 0x03 0x02 0x03 0x06 0x03 0x04 0x602110 <gameData+80>: 0x02 0x06 0x03 0x05 0x00 0x00 0x00 0x00 0x602118 <gameData+88>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602120 <gameData+96>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602128 <gameData+104>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602130 <gameData+112>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602138 <gameData+120>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602140 <gameData+128>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602148 <gameData+136>: 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x602150 <gameData+144>: 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x602158 <gameData+152>: 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x602160 <gameData+160>: 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x7a 0x00 (gdb) 0x602168 <gameData+168>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602170 <gameData+176>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602178 <gameData+184>: 0x1a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602180 <gameData+192>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602188 <gameData+200>: 0x03 0x09 0x03 0x0b 0x02 0x09 0x01 0x0a 0x602190 <gameData+208>: 0x01 0x0e 0x03 0x0c 0x02 0x0c 0x03 0x08 0x602198 <gameData+216>: 0x01 0x0b 0x01 0x0d 0x01 0x09 0x00 0x0c 0x6021a0 <gameData+224>: 0x02 0x0b 0x02 0x0a 0x00 0x0a 0x00 0x0d 0x6021a8 <gameData+232>: 0x02 0x0e 0x00 0x0b 0x03 0x0e 0x03 0x0d 0x6021b0 <gameData+240>: 0x01 0x0c 0x00 0x0e 0x03 0x0a 0x02 0x08 0x6021b8 <gameData+248>: 0x02 0x0d 0x00 0x09 0x00 0x00 0x00 0x00 0x6021c0 <gameData+256>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021c8 <gameData+264>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021d0 <gameData+272>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021d8 <gameData+280>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021e0 <gameData+288>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021e8 <gameData+296>: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6021f8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x602200: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
こんな感じになってます。name配列へはzzzzz…を入力してあり、0x7a(=z)が並んでいるところがname配列です。他ずっと0が並んでいるのがわかるかと思います。
なお、checkInvalidCard関数でカードの値(suit<=4, value<=14でないと不正)がチェックされるので、それに違反しないようにしなくてはなりません。
解法
よって、まずname配列への名前の入力時に32文字、checkInvalidCard関数に引っかからない4以下の値を入れることで、readInput関数のバグを利用しdeckSize変数の下位1バイトに0を入れます。26回の勝負を行わせ正規のカードを使い切らせ、確保されているカード配列は全部で52なので、追加で(52-26=)26回の勝負を行います。そうすると人間プレイヤーはカードとして(カード配列の次に配置されている)name配列の領域を、コンピュータプレイヤーはカードとして(カード配列の次に配置されている)0が並んでいる領域を読むため、その後の勝負で勝利することができます。
よって、name配列への入力として0x04を32個、そのあとカードを使い切るために適当に少ないベットで勝負を繰り返すため、適当に1を52回送信し、そのあとはこちらが勝つのでたくさんのコインをベットしていきます。
冒頭に挙げたwriteupでそのスクリプトが公開されています。
picoCTFのサイト上のシェルからでなくローカルのシェルからエクスプロイトコードを実行して得たflagは、なぜか受け付けてもらえなかったので、picoCTFのサイト上のシェルでやらざるを得ませんでした。
ctrl+V, ctrl+Cで0x03が入力できます。連打でがんばれ！
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Menlo; color: #000000; background-color: #ffffff}
コメント