ワットイズディス?ヒント1:セキュリティが大好きな大和魂なら分かります!との事なので、日本語の文字列として無理矢理読んで大和セキュリティ。nanee?フラグは漢字一文字で願い申し上げ候。画像はそのまま漢字であるとすると、忍かなと推測。Boxes文字の背景の模様が無意味に見えたので、とりあえずこれを消してgoogle画像検索に。Culture)みたいなのが引っかかる。壱萬回10000回解けばよい。stdinやstdoutにpipeを繋ぐと、flushがなされないのか、問題の式が出てこない。ぐぐると、pexpectが良さげ。isatty関数を上書きするような方法もでてきたが、動かなかった。total10分掛かった。5zipを解答すると、文字が1つ書かれた画像がたくさんでてくる。filesファイル名に意味はあるのだろうかと検索すると、md5によるハッシュ値で、単一の数字であるということが分かる。-この数字の順に画像を読むと、KOUBE-GYU。暗号で検索すると、忍者文字というのがでてくるので変換。ヤマトイエバと出るがこれはflagではなく、川と答える。craSH適当に色々試してたら勝手に答えがでてきた。enough!flag={NoMoreBashdoor}問題だったのは関数args_cat。*output);引数として指定されたファイルと出力先として指定されたファイルが同一のときが問題。引数のファイルたちの長さの総和を求め、出力先のファイルの長さに代入し領域を確保する。これにより引数のファイルの長さの総和が変化してしまい、確保した領域より長く書き込んでしまう。Aikotoba逆変換をする。00])))'Yama'次もやるだけ。[0o164,111,0x6f]))'too'整形/整理して理解した内容を使って枝を刈った上でloopを回す。KansaiTanaka。0;}短いのでそのまま総当たり。1;}適当におおきいの突っ込んだら答えがでてきた。2与えられるソースをよく読めばそう難しくはない。heap上のoverflowであるがmetadataを操作する必要はほぼなく、64bitであることも特に効いてこない。craSHの続きである。heap上でのoverflowを使った攻撃となる。*dataの中身である。*であるfile.dataを書き換えれば、任意のアドレスへの読み書きが可能になる。これができたとして話を続ける。RELROなのでgotへの書き込みは可能であるので、これを使う。enabledが立っているのでheap上にshellcodeを置いても機能しない。craSHソースをよく読むと、strchrのgotをsystemへのアドレスに書き換えれば、shellscript片を実行させられることに気付く。...}xinetd型の問題であるのでこれで十分である。strchrのアドレスをleakさせることができ、libcは与えられている。よってこれでflagが手に入る。overflowによる任意のアドレスの読み書きである。プログラムをcrashさせてしまうと失敗となるので、必要な場所のみを正確に書き換えなければならない。今回はどの領域も小さいので、chunkのmetadataはそのchunkの大きさのみである。これを壊さないように気を付けるだけでよい。('!')が一定感覚で見られるだろう。ファイルの中身のdataをoverflowさせfile構造体のfieldを書き換えたいので、heap上でこのふたつのchunkが連続するように準備する必要がある。単純にファイルを作製していくと確保の順番の影響でそうはならないが、一旦確保した領域をreallocで拡張する際に移動させるとこれが可能になる。\nとするとファイル$bのdataの直後にファイル$cのfile構造体が置かれる。