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

typeすつーか

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

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

広告とか

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
--/--/-- --:-- スポンサー広告 TB(-) CM(-)
# this is kusocode...

runes = ['f', 'u', 'th', 'o', 'r', 'c/k', 'g', 'w', 'h', 'n', 'i', 'j', 'eo', 'p', 'x', 's/z', 't', 'b', 'e', 'm', 'l', 'ng/ing', 'oe', 'd', 'a', 'ae', 'y', 'ia/io', 'ea']

tmp = reversed(runes)
rrunes = []
for var in tmp:
rrunes.append(var)

#-----

origin_upper = 'R NGRAMW JIHEIIAI MAEYW EAAAEN'
origin_lower = origin_upper.lower()
o_list = list(origin_lower)

input = []
for var in o_list:
input.append(var)

#====
#func
#====
def decode_char(c):
if c == " ": return " "
dex = runes.index(c)
out = rrunes[dex]
return out

out_str = []
def pack(list):
for var in list:
out_str.append(decode_char(var))

#==================================
# Execution part
#===================================
print 'Starting decoding....'


pack(input)
print out_str
ans = "".join(map(str, out_str))
print ans
2014/05/15 22:53 未分類 TB(0) CM(0)
この記事はProcessing Advent Calendar 2013の27日目です。

こんにちは、すつーかです。
よく"すーつかさん"って呼ばれますが、すつーかです。

processingでネットワークSnifferとか作れないかなとか思って調べてみたらライブラリ見つけました。
もう誰かが作ってくださっていたようです。
さっそく試してみましょう。

Carnivore
RSG / Carnivore | github

で、こちらがサンプルを実行した動画↓

Carnivore Processing Sketches from Caroline Brown on Vimeo.



どうですか!
ワクワクしてきませんか!?
僕はワクワクドキドキしてきました!

ipアドレスの第3オクテット目をx座標、第4オクテット目をy座標としているようです。(たぶん

でもちょっと残念なことが。
Dropboxっぽいアイコンとか、SkypeのIMっぽいアイコンとか、iTunesっぽいアイコンとかありますよね?
ソース見て分かったんですが、これ実は

...適当に割り振ってるだけだったのです




というわけで自分なりに作ってみました↓

processing_carnivore_extends from Type Stuka on Vimeo.



Dropboxとのトラフィックを検出するとDropboxのアイコン、同じくtwitterのアイコンも表示するようにしてみました。
いいですね〜。今自分がどんなサービスを利用しているか、あるいはバックグランドでどんなサービスが動いているかが見れてとても興奮しますね^〜^
ipアドレスの都合上、とても小さく描画してますが、ちゃんとipも一つ一つしっかり描画しています。
nslookupのクラスもpdeで作って、ipアドレスからドメインを取得し、描画できるようにもしました。
あと、赤色のノードがローカルのPCです。ひと目でわかって便利!


Sample3には、テキストファイルにログを保存しておけば再生してくれる機能があります。
ログファイルっていうのはこんなかんじの形式でした↓
p5logfile.png


時刻と送信元ipアドレスと送信先ipアドレスですね。
これくらいのログなら既存のpcapファイルからスクリプト使って出力できそうです。
(...というかwiresharkのexport機能で出力できたような...?)
pythonを使ってログファイル作るスクリプト書きました。


これを使えばWireshark SampleCapturesのパケットも簡単にログファイル出力できますね。
NTPとか、UDP通信のものはスクリプトのtcpをudpに置き換えて使ってください。


で、いろいろ再生してみました(。∀。)


Wireshark SampleCaptures

TELNET↓

Visualize telnet-raw.pcap from Type Stuka on Vimeo.




NTP(ポート番号を描画するようにしました。おもいっきりNTPのポートですね!)↓

ntp traffic from Type Stuka on Vimeo.





P5erの皆さん!
processingでTCP/IPのスイスアーミーナイフ作りませんか!?


ではまた!
2013/12/25 05:35 processing TB(0) CM(0)
こんにちは、すつーかです。
このエントリは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)
こんにちは、すつーかです。
昨年のProcessing Advent Calender2012に引き続き、今年も参加させていただきました。
Processing AdventCalender2013 23日目の記事です。

昨年のアドベントカレンダーではprocessingでゲームを作っているエントリを書きましたが、あれからいろいろありまして、セキュリティ界隈に首を突っ込み、ctfに参加したりするようになりました。

そこで、processingを使ってctfの問題を作りました。ジャンルはnetworkです。

homuhomu.zip

興味のある方はぜひ一度チャレンジしてみてください!


26日頃、解答編を公開する予定です!
2013/12/22 18:38 AdventCalender TB(0) CM(0)
チームL3のravencodingです。
はじめてSECCONに参加しました。
前日は緊張しすぎて楽しみすぎてなかなか寝付けませんでした。
「(NewsZEROに出てたみむらさんに生で会える...! )」
「(竹迫さんにも生で会える...!)」
(まさに、”むっちゃドキドキしてきた...”ですね(ゲフンゲフン


フォレンジックスのwriteupです。


---
指令部からの暗号文を解読してください

DiskImage.dd
---
500pt...(゚A゚;)ゴクリ

DiskImage.ddをAutopsyに食わせて見てみると、Message.txtと削除された画像ファイルが見つかりました。

Message.txt↓


司令部からのメッセージを送る。

VRZGNWSOHPMY

位置については、これまでと同様に写真を参照してくれ、
くれぐれも写真は忘れずに削除するように!!



削除されてた画像↓

tank.jpg

zero.jpg

google画像検索にかけると、タンクが「九五式軽戦車」零戦っぽいのが「西沢広義」と出た。
タンクの名前で検索したらガルパンが出てきたので焦った。
   (え、ガルパン関係なん...? アニメ見てないよ><; 艦これもやっとけばよかったかな><;)←と感じたけど特に深い意味は無いだろうとスルー。


ここで歴史に詳しいチムメンがWW2の頃はパープル暗号ではないかと写真見て即刻答えてくれた。
パープル暗号でぐぐってみると、日本版のエニグマらしいことがわかった。

とりあえず画像をバイナリエディタで覗いてみると、F6 Exif Version 0.9.0bという意味ありげなワードが見えたのでググってみる。
tool.png
すると、同じ名前のツールが見つかったので使ってみる。

exiftank.png
exifzero.png

ユーザコメントのところに
Rotor position 1:J
Rotor position 3:N
とあったので、アルファベットずらす回数かなと思い、submitするもwrong。



1時間くらいパープル暗号で解こうとしたけどそもそもパープル暗号がどういう手順で暗号化・復号化しているのかわからなかった。(時間かけすぎ;

パープル暗号について詳しく解説している記事がネットで見つからなかったので、エニグマ暗号のページを読むことにした。
問題 1926年 エニグマによる暗号通信開始
ここの画像を見てみると、ロータ1とかロータ2ロータ3と書いてあったので閃いた。
先ほどユーザコメントで見かけた


Rotor position 1:J
Rotor position 3:N


だが、もしかすると、

Rotor position 2:□


がダンプファイルの中に隠されているのではないかと睨んだのだ。

僕はAutopsy使いではないのでAutopsyでキーワード検索できるのを知っていたチームリーダに
「2:」で検索して!と依頼。

予想通り、

Rotor position 2:P


がヒット!

もしかすると、エニグマ計算機で復号できるんじゃないかと考えて、ネットでエニグマ計算機を探すも見つからず、
(予選終了後にググったら普通にヒットしてたので調べ方が悪かったんだろう)
どうしようかと悩んでいたところ、もう一人のチムメンが「Androidアプリでエニグマシュミレータありますよ」との情報を。
Screenshot_2013-12-02-01-16-04.png

さっそくインストールしてつかってみるも、エニグマ計算機のreflectorが3種類ある模様。
3つのreflectorを全てためしみて復号&submitすると正解だった。

FLAGワード↓
TORATORATORA

由来としてはこれ↓みたい。ワレ奇襲ニ成功セリ
トラトラトラ - Wikipedia


チーム全員で解いた感じでした。
歴史に詳しいチムメン、
Autopsyのキーワード検索機能を知っていたチームリーダ、
AndroidアプリでEnigmaシュミレータを見つけてくれたチムメン、
Androidアプリのreflector3種類総当りで500ptゲットした僕。
全員が絶妙なヒントを出し合って初めてとくことが出来ました。胸熱ですね(ぇ


あと、北陸予選二位のdendenbiyoriチームの方のwriteup見てると、僕らとはかなり解き方のアプローチが違ってておもしろかったです。


ちょっと残念だったのはこれ↓




最後に一言、
ORIJHHZOMBY
2013/12/02 01:39 ctf TB(0) CM(0)
検索フォーム
ブロとも申請フォーム
QRコード
QR
IPv4枯渇時計
linuxコマンド
ぶくろぐ
本棚です
icat
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。