お絵描きやプログラミングやアーマードコアについて綴っていくつもりです。プログラミングは備忘録的に使うつもりだったりする。
プロフィール

Author:typeすつーか
FC2ブログへようこそ!

最新トラックバック
カウンターです
ついったー

広告とか

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
--/--/-- --:-- スポンサー広告 TB(-) CM(-)
こんにちは、すつーかです。
このエントリはProcessing Advent Calender2013 26日目の記事です。
23日目に出題した問題の解答編となります。

「どこらへんがprocessingなんだ?」
と思われてしまうかもしれませんが、パケットを生成する部分にprocessingを用いました。
processingで作った経緯をお話します。

SECCON2012にて、パケットごとにアルファベット一文字ずつdataに入れて送信するという問題が出題されているのを見つけました。
それを知って一つの疑問が浮かびました。


( ˘⊖˘) 。o(こんなパケットって、一体どうやって作るんだろう?)
( ˘⊖˘) 。o(scapyかな? でもscapy使ったことないしなぁ...)

       |
   \  __  /
   _ (m) _ピコーン
      |ミ|
   /  .`´  \
      ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    (・∀・∩< そうだprocessingならきっと実現できる!
    (つ  丿 \_____________________
    ⊂_ ノ
      (_)


というわけで作りました。

はてさて、processingがどのようにしてhomuhomu.pngファイルに用いられているのか?
以下、問題の解説になります。


とくとご覧あれ!




問題ファイルを開くと、なにかのキャラクターのアスキーアートを画像にしたものであることがわかります。
homuhomu.png



とりあえず、CTFでよく使用されるfileコマンドを実行すると,

-(stuka@stukaMac)-(0)-<2013/12/22 19:28>---[...tuka/VirtualBox VMs/share/test]-
-[11604] ( ◠‿◠ )☛ % file homuhomu.png
homuhomu.png: PNG image data, 573 x 372, 8-bit/color RGB, non-interlaced


となります。
んー、fileコマンドではPNGファイルと判定されたようですね。


stringsコマンドも試してみましょう。

-(stuka@stukaMac)-(0)-<2013/12/22 19:31>---[...tuka/VirtualBox VMs/share/test]-
-[11605] ( ◠‿◠ )☛ % strings homuhomu.png
IHDR
tEXtComment
looping 10 times!^
IDATx
?{3O"
:
:
:



お、なにやら意味のありそうな文字列がでてきました。

pngのコメント部分であるtEXtチャンクを見てみましょう。
strlingで開きます。
text.png



どうやらstringsコマンドで表示された文字列は、PNGのコメントだったようですね。


せっかくHEXエディタで開いたのでビットイメージも見てみましょうか。
bitimage.png



おっと、なにやら画像ではなさそうなバイナリがみえますね。


pngのENDヘッダよりも下部に付加されているようです。
切り取って保存してみます。
fileコマンドで調べてみます。

-(stuka@stukaMac)-(0)-<2013/12/22 19:05>---[/Users/stuka/VirtualBox VMs/share]-
-[11596] ( ◠‿◠ )☛ % file binary
binary: data



...データ形式と表示されてしまいました。ただのデータのファイルまたはfileコマンドのサポート外のヘッダである可能性があります。

stringsコマンドも試してみましょう.

-(stuka@stukaMac)-(0)-<2013/12/22 19:05>---[/Users/stuka/VirtualBox VMs/share]-
-[11597] ( ◠‿◠ )☛ % strings binary
Linux 3.2.6
Dumpcap 1.8.1 (SVN Rev Unknown from unknown)
Linux 3.2.6
# Zm
# Zm
# Zm
JDWP-Handshakep
JDWP-Handshakep
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
# Zm
Counters provided by dumpcap



dumpcapをググると、wiresharkの単語がでてきました。
wiresharkで開くことができるのでは?
と推測してwiresharkで開いてみます。

開けました。
wiresharkprocess.png



ループバックアドレスで、dnpポートと54974ポート間でなにかのやりとりが行われているようです。
ports.png

フィルタをかけてみます。
tcp.srcport == 54974
一層見やすくなりました。

パケットを眺めるとechoサーバー、クライアントのやりとりをキャプチャしたように見えます。
もっと詳しく見てみると、data部にアルファベット一文字ずつ送信されていることがわかります。
packetdatadata.png



一つ一つ文字が送られてきているということは、全てを順番に連結してみれば、何か意味のある文字列になるのでは?

パケットからdataを取り出して一文字ずつ繋げてみましょう.
手動でやってもいいですが、全部で460文字あるので、一文字3秒かかると計算しても23分ですね。
手動でも無理ではないですが、打ち間違えなどを考えるとあまりスマートではないかもしれません。
というかFollowTCPStreamで一発ですね。でもそれじゃぁ面白く無いのでスクリプト書きました。

今回はpythonを使いました。
なお、dpktを使用する際は、pcapng形式からpcap形式に変換する必要があります。


root@bt:/media/sf_share/test# editcap -F libpcap binary.pcap out.pcap






dpktextract.png


実行します


root@bt:/media/sf_share/test# python getBase64.py

Vm0wd2QyUXlWa1pOVldSWVYwZDRWRll3Wkc5WFZsbDNXa1JTVjFKdGVGWlZNakExVmpKS1NHVkVRbUZXVmxsM1ZtMTRTMk15U2tWVWJHUnBWMFpHTTFkV1pEUlRNbEpJVm10c2FsSnRhRzlVVmxwV1pVWmtWMWR0ZEZSTlZUVllWVzAxUzFsV1NuUmhSemxWVmpOT00xcFZXbXRXTVdSMFVteFNUbFl4U2twV2JURXdXVmRHYzFOdVVsWmhlbXhoVm1wT2IyRkdWbk5YYlVaWFZtczFlRlpYZUZOVWJGcDBaSHBDVjAxdVVuWldha1poVTBaT2NtSkdTbWxTTW1ob1YxZDBhMVV5VW5OWGJrNVlZbGhTY1ZsclpEQk9iR3hXVjJ4a1ZXSlZWalpWVjNCaFZqRmFkRlZVUWxkaGExcFVXWHBHVDJOc1duTlRiR1JUVFRBd01RPT0=




これは54974ポート行きのパケット一つ一つのdata部を結合した結果です。
英数字と末尾に=があることからBase64Encodeと見て間違いないでしょう.

ここでtEXtコメントに書かれていたことを思い出します。

"looping 10 times!"


10回ループせよ!
ですね。

Base64Decodeを10回ループ処理で実行してみます。
pythonなら簡単にかけますね。



pythonbase64flag.png


実行します.


root@bt:/media/sf_share/test# python 10base64.py
Learning the vi Editor



"Learning the vi Editor"
と出てきました。

これが答えです。


パケット生成部分


パケット生成とまで言えるかはわかりませんが、以下のコードをサーバーを起動してからクライアントを起動すればパケットが流れるので、その時にWiresharkなどでキャプチャしました。


友達に解いてもらったのですが、FollowTCPStream機能を知らなかったらしく、data部分を全部テキストファイルに出力して、そこからダブったところを削除するスクリプトつくってBase64のコードをとりだしてました。でもBase64ではない記号が変換途中ででてきてしまい、詰まっていました。

その友達が発見してくれたのですが、パケットごとに1byteのデータ送っているつもりだったのが、まれに2byteのデータを送信しているパケットがありました。
( ˘⊖˘) 。o(1byteずつ送信してるつもりだったのに、どうしてたまに2byteずつ送信してしまっているんだろう...?)

原因がよく分からなかったので、研究室の先輩に聞いたら一発で教えてくれました。
「パケットが送信される前にNICのバッファにたまって、たまった分が送信されるから、その分が2byteになってると思う」
ということでした。

試しにsetup()でframeRate(10)と設定すると、ちゃんと1byteずつ送信してくれました!

適当なfpsでキャプチャしたデータを置いておきます↓
240fpsだと3byteになってたりしました。
homuhomu.pngに埋め込まれてたもの
10fps.pcap
120fps.pcap
240fps.pcap


あとがき


今回、ネットワークに関する問題をprocessingを使用して作成しました。
CTFではジャンル:Networkの問題が少ないので、processingを用いて気軽に作れるようになれば
いろいろな問題がたくさん生まれるのではないでしょうか?
(たとえばprocessingでオンライン対戦のゲームつくって、それを題材に問題作るとか...?)

パケットごとに一文字ずつ送信するといった手法は有名になってきている今、
processingを用いて新たなアイデアを持った問題を作っていきたいと考えています。
良い問題ができたらFlaggersにも投稿したいものです。
それではまた!


参考リンク


「NIC ハードウェアバッファー」

スポンサーサイト
2013/12/22 23:27 AdventCalender TB(0) CM(0)
コメント















 管理者にだけ表示を許可する

トラックバック
http://stukacoding.blog.fc2.com/tb.php/120-8461ec28
検索フォーム
ブロとも申請フォーム
QRコード
QR
IPv4枯渇時計
linuxコマンド
ぶくろぐ
本棚です
icat
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。