BYでカラム名をエラーメッセージとして表示させてみた所、使えそうなカラムが以下のような感じである事が判明しました。(以上3カラムの内容その他をカンマで区切って連結したもの)そこで、以下のようなクエリを投げて(うろ覚え)、全checking口座のbalanceとownerを列挙した所、balanceが全て0.00であることが判明。Mossの口座を突き止める事にします。accountテーブルでは口座所有者の情報はownerの数値しか見つからなかったので、別のテーブルの情報と結びつける事を考えました。今一度テーブル一覧を眺めると、customerなるテーブルがあるようです。customer.lastnameがあるようなので列挙させました。Moss"で検索した所、Wikipediaに以下のような記述を発見。conferences."Tangent"でページ検索をかけたら、居ました。(どんな名前だ...)彼のcustomer.idが分かったので、account.ownerと結びつけた上でaccount.balanceを今一度確認しましたが、やっぱり0.00です。仕方がないので、"0.00"と解答した所、"CORRECT!"となり400ptをゲットしました。非効率極まりないですねorzaccount.ownerとcustomer.idが同一の値であるという前提も勘に寄ったものですし、これは好ましくない解法です。全ユーザーのbalanceが0.00だったのは、何かの間違いだったのか、それとも意図されたものだったのか...。Injectionはあまり知らなかったので、いい勉強になりました。300も解きましたが、概ね辻さんと同じアプローチでした。CTF福岡大会のレポートを、実行委員の園田さんが@ITで執筆されていました。僕は残念ながら参加する事が出来なかったのですが、大会で出題された問題の内の一題がレポート中で引用されていたので、解いてみました。以下、そのレポート(とオマケ)です。ネタバレを含むので、これから解こうと思っている人は注意してください。問題は「以下のファイルダンプは宇宙からの中性子線で1bitのデータが反転したものである。(略)1bitだけ異なる正常なデータファイルを復元し、秘密の鍵を答えよ。実行委員長の竹迫さん作成の問題です。ダンプのテキストを素のバイナリに戻します。corrupted.binとすると、素のバイナリがcorrupted.binとして保存されます。次に、corrupted.binがどういうファイルなのか調べます。fileコマンドに入力したところ、出力は以下の通りでした。violatedとなりました。確かにこのファイルは破損しているようです。2856bitsで、反転したビットは1ビットのみである事が分かっているので、総当りで1bitずつ反転させて解凍を試みる方法が現実的に実行可能であると推測できます。-dを試みて、そのうちの1つ、ファイル先頭から383bit目を反転させたファイルの解凍に成功しました。その中身がまさに「秘密の鍵」だったのですが、それは敢えてここには書きません。自分でやってみましょう。オマケとりあえず上の方法で解くことは出来たものの、この流れではおそらく定石であろう総当たりだけをして終わるのは、もったいない。いうわけで、エラーメッセージを手がかりにした総当りによらない反転箇所の絞り込みを試みました。treeという文がいかにも反転箇所の手がかりになりそうです。tree"が何処にあるのか突き止めるため、まずはgzipのファイルフォーマットについて調べます。ヘッダ"等でぐぐって、以下のページを発見しました。format上のページの内容とcorrupted.gzのバイナリを突き合わせた所、corrupted.gzの中身は以下のようになっている事が分かりました。+-----------+-------------+---------+---------+|header(16B)|payload(333B)|CRC32(4B)|ISIZE(4B)|+-----------+-------------+---------+---------+括弧内の数字はその部分のバイト数を表しています。tree"らしき物が無いので、どうやらペイロードが怪しいです。ヘッダによれば、このペイロードにはDeflateで圧縮されたデータが格納されているとの事なので、今度はDeflateについて調べます。出てきた以下のページを参考に考えてみることにします。ウェブで用いられる画像形式。files上のページ曰く、Deflateのバイナリの構造はこんな感じ。+---------------+---+今度は、括弧内の数字はビット数を表しています。tree"を指しているようです。反転していると思しき部分はこれで判明しましたが、問題はその範囲です。distance"の範囲を求めるのは容易ではありません。するとこの世の何処かにはDeflateのバイナリをそのまま読んで解読できるイカれたよく訓練されたバイナリアンが居るのかもしれませんが、僕には無理です。そこで、gzipコマンドのソースコードを弄って、解凍中に当該部分の範囲を出力させてみる事にしました。gzipのソースコード(gzip-1.4.tar.gz)を落としてきて、まずは元々のエラーメッセージでgrepします。inflate.cのinflate_dynamic関数中でエラーとなっているようです。distance"までを読み込んでいる事が分かりました。DUMPBITS(j);printf("%d,",j);という風にinflate_dynamic関数中のDUMPBITSマクロを置換し、読み込みが発生する度にそのビット長を出力させる事にしました。distance"部分に入ったら"D"という文字が出力されるようにしました。以上の改造を施したgzipでcorrupted.gzの解凍を試みると5,5,4,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,4,3,3,3,3,3,4,7,4,4,3,2,4,7,4,7,2,4,3,3,3,3,3,2,2,2,2,4,2,6,4,4,2,4,2,2,2,2,2,3,3,6,D,2,4,3,3,3,2,3,2,6,2,4,2,6,2,2,3,2,3,2,2,2,という文字列が出力されました。401bitの範囲にある事が分かりました。実際に反転していた箇所は383bit目なので、求まった範囲とも合致します。これにより、総当りによらず、反転していると推測される箇所の範囲を60/2856まで絞り込むことが出来ました。まとめこの問題については、範囲絞り込みの手間より総当りの手間のほうが明らかに少ないので、総当たりを選ぶべきです。問題によっては、何かしらの方法で範囲を絞り込む事が必要になることもあるでしょう。誤りがあれば指摘お願いします。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。