はじめに

picoCTFに取り組んで行くときの考えていたことを書き記す。writeupというより、解いた道筋を書いていますので、最短距離を知りたい人にとっては意味わからないものかもしれません。ご了承ください。begginerのお戯れと思って暖かく見守っていただければ幸いです。フォレンジックをメインにやっていこおうと思っています。

開閉

はじめに
Matryoshka doll
tunn3l_v1s10n
- 知識(バイナリ, ビットマップ, オフセット, リトルエンディアン)
Glory of the Garden
- 知識(JFIF)
Wireshark doo dooo do doo...
- 知識(wireshark, pcapng)
- 知識(wirshark色規則, プロトコル, HTTP, TCP)
- 知識(TCP通信のコントロールフラグ, TLS)
MacroHard WeakEdge
- 知識(xml)
- 知識(pptmとpptxの違い)
- 知識(findとgrepコマンド)
- 知識(エンコード, デコード)
- 知識(文字コード, 文字エンコード)
Trivial Flag Transfer Protocol
- 知識(ARP, SSDP, TFTP)
- 知識(debフォーマット)
- 知識(アーカイブ)
- 知識(strghide)
Enhance!
- 知識(svg)
Lookey here
Packets Primer
Redaction gone wrong
So Meta
- 知識(exiftool)
shark on wire 1
extensions
What Lies Within
Sleuthkit Intro
- 知識(mmls)
- 知識(.img)
PcapPoisoning
- 知識(FTP)
- 知識(TCP Retransmission)
hideme
Wireshark twoo twooo two twoo...
- 知識(DNS, GQUIC)
who is it
Sleuthkit Apprentice
Disk, disk, sleuth!
Disk, disk, sleuth! II
Pitter, Patter, Platters
- 知識(slack space)
Operation Orchid
advanced-potion-making
like1000
- 知識(bashプログラミング)
WhitePages
Eavesdrop
- 知識(DHCP)
- 知識(TCP通信盗聴対策)
WPA-ing Out
- 知識(rockyou.txt)
- 知識(無線LAN)
FindAndOpen
- 知識(Ethernet)
shark on wire 2
WebNet0
- 知識(TLSv1.2)
Operation Oni
WebNet1
Torrent Analyze
- 知識(Torrent)
- 知識(BitTorrent DHT Protocol)
- 知識(wireGuard)
- 知識(peers, leechers and seeds)
scrambled-bytes
- 知識(ポート)
- 知識(ICMP)
- 知識(タイムスタンプ)
Scan Surprise
Verify
CanYouSee
Secret of the Polyglot
Mob psycho
- 知識(android apk)
Dear Diary
- 知識(USNジャーナル)
ここ以降未解決
- File types
  - 知識
  - 知識
  - 知識
UnforgottenBits
St3g0
Milkslap
Very very very Hidden
- 知識(443ポート)
- 知識(HTTPステータスコード一覧)
- 知識(pngとzlib)
- 知識(QUIC)
- 知識(favicon.ico)
endianness-v2

Matryoshka doll

　画像を渡された。そこからFlagを探しに行く問題。
まず初手fileとstringsで情報を探しに行く。しかし、PNG imageという情報くらいしか把握できなかった。(もしかしたらほかにも得れたのかな？)
そこで、ctfで画像を渡された時の対処法を探したとき、exiftool, binwalkがあることを知った。(Forensics入門（CTF） - Qiita)。
binwalkの結果を見るとzipデータが埋め込まれていることが分かった。

　中に埋め込まれたものを抽出するために-eオプションを利用する。安全性の警告から、root権限で実行してとのことだったので--run-as=rootをつけて実行(安全性が保証されない画像に対しては仮想環境下で行うのが安全だと思われる)。そうするとzipからbase_imageとzipファイルが抽出できた。base_imageにある画像に対して同じコマンドを実行していくとflag.txtが見つけられるので、catしてflagゲット。

考察

　画像にファイル等を埋め込むことができ、ここに悪意のあるのもを埋め込むことで攻撃につながっていくのだと思う。

tunn3l_v1s10n

　渡されたファイルからflagを復元する問題だろうか。
まずは初手file、dataタイプ。これでtextやexecutableではないことがわかった。定石はバイナリファイルか表示不可能なファイルだそうだ。次にstirngsコマンド。大量に流れた。初めの10行を出力のようにしてみていく。100行まで見たが可読できそうにない。バイナリファイルとにらんで処理していく。hexdumpで文字列にしていく。上から200行を出力したが、あまり有力なのがない(たぶんヒントあるんですよね)。
　ここでお手上げwriteup見てお勉強。(picoCTF 2021 tunn3l v1s10n Writeup - Qiita,picoCTF 2021 Writeup　うさみみハリケーンで解いてみた ) 　hexdumpの最初に情報があったらしい。BM。bitmapというものらしい。画像データの中にflagに関する情報が含まれているように考えられる。パレットデータをいじる意味もあまりなさそうと考えるとファイルヘッダと情報ヘッダにアプローチするのが良いと考えられる。赤い枠がファイルヘッダ、緑が情報ヘッダ(40byteと仮定している)である。
　まずファイルヘッダ。42,4dはBM(※ファイルタイプはリトルエンディアンじゃない！) 002c268eがファイルサイズ。予約域はどちらも0。0000d0ba(53434)はファイル先頭から画像データまでのオフセット。オフセットは大きい可能性がある。情報ヘッダが可変であるのでそれに応じて大きくなる。以上のところでは問題なさそう。

知識(バイナリ, ビットマップ, オフセット, リトルエンディアン)

バイナリ

バイナリエディタが利用されていたのでバイナリエディタ関連を述べる。出力 hexdump以外に、xxdというコマンドでもバイナリ(16進)、ASCIIが出力される。編集 hexeditor　ファイル名で表示と編集ができる。 vi -b ファイル名でvim上で編集可能。ダンプ形式に変更するなら:%!xxd。編集後に保存するなら:%!xxd -r 実行後:wqで保存。バイナリファイルの編集方法 - Qiita

ビットマップ

画像や文字データの形式はビットマップ画像とベクタ画像がある。 https://wa3.i-3-i.info/word1653.html ビットマップのデータ構造の話をしましょう。 bitmapファイルはファイルヘッダ(14byte)、情報ヘッダ(40byte)(←bitmapの種類で変わる。)、パレットデータ(情報ヘッダのパレット数で変化する4byteずつ変化)、画像データ(任意)の4つの部分から構成されている。【バイナリファイル入門】Bitmapファイルを手書きで作って遊んでみる - Qiita このサイトめちゃくちゃわかりやすかった

オフセット

ある基準からの距離で表した位置。 https://wa3.i-3-i.info/word11923.html

リトルエンディアン

バイト列の並べ方。一番最後のものから並べていく方式。 https://wa3.i-3-i.info/word11428.html

　次に情報ヘッダ。0000d0ba(53434)は情報ヘッダサイズ。ここがおかしいらしい。情報ヘッダサイズはオフセットより0xEだけ小さくないと画像データ開始位置がおかしいことになる。今の状態はあまりにも大きい。情報ヘッダを40と仮定しているので0x28として保存。何かしらの画像が見えた。notaflagなので何かが違う。おかしそうなところを考えていく。

ファイルサイズ：ls -lで確認したが、一致している。(2893454byte)
offset：異なっていたのでファイルサイズから画像データサイズを引いた54(0x36)にしてみる。きれいになったがnotaflag。
縦横と解像度の縦横：解像度が正方形に対して縦が短い。

　計算して適切な縦サイズを求めていく。画像サイズ = 縦サイズ×横サイズ×1ピクセルあたりのカラーbyteである。情報ヘッダから1ピクセルあたり0x18(24)bit使っている。つまり、1ピクセル3byteサイズにかかっている(ビットマップ画像のデータ量 )。画像データサイズはファイルサイズ内にあり、画像もきれいなので異常なしと判断。
今のサイズで計算すると、1134×306×3=1,041,012となり、画像サイズより小さい。小さい分を縦サイズで調整する。縦サイズを0x352として実行。成功！

参考

　画像のヘッダ情報による変化や拡張子のないことによる判定の難しさを知った。ヘッダ上の縦と横のサイズをいじると見え方が変わることによって、メモリ上に載せることのできる範囲が変わるのならば、画像に悪意のコードを載せて、攻撃の際に画像を加工することで実行させるような攻撃につながるように考察できる。

Glory of the Garden

　画像データが渡された。多くの情報が含まれていて、その中にflagがあるようだ。初手file JPEGデータであるのは拡張子からもわかる。他はあまりわからない。もしかしたら重要な情報あるかも。
次にstringsコマンド

知識(JFIF)

JFIF

.jfifとは、JPEG形式の画像データを「ファイル」として保存するときに利用される拡張子です。

　ちなみにstringsコマンドを全部出力すると最後の方にflagがあった（こんなにあっけなくてよいものか）。もう少しコマンドを実行してwriteupを探す。
次はbinwalkで埋め込みないかを確認。なにやら埋め込まれていそう。著作権表示が埋め込まれている。透かしのようなものだろうか。

考察

よくわからなった。stringsやbinaryを見たらすぐに見つかる。他の意図がありそう。

Wireshark doo dooo do doo...

Can you find the flag? とともにpcapngファイルが与えられている。

知識(wireshark, pcapng)

wireshark

Wiresharkは、LAN上に流れているパケットを「見える化」するパケットキャプチャツールです。wireshark以外にtcpdump(WinDump)なるものでもできるようだ。様々なAPIで構成されており、cで実装されている。 Wiresharkの使い方～Wiresharkで「TCP/IP」モデルをのぞき見る～ | ハートランド・ザ・ワールド (hldc.co.jp)

pcapng

パケットの見えるかで見えるようになったもののファイル形式の一つであるようだ。 pcapファイルはPCAP Header(24byte)とPaket Header(16byte)と Raw Packet(任意)で構成される。それぞれのヘッダー内にもまたいくつもの決まった情報が格納されている。次にpcapngはpcapより機能的になったそうです。セクションで構成で構成されている。またそのセクションはブロックというもので構成されているようだ。 PcapとPcapNGのフォーマットの違いを詳しく調査する！ | MasaのITC Life (wireless-network.net)

　さて、今回はpcapngの解析ということで、まずwiresharkを使いたいと思う。初めて触れるのでわくわく。通信をクリックするとその時のやり取りを見れるようになっている！すごい！つまり、この通信ログ内からflagのやり取りを見つけ出し、それを見に行くことが求められていると考えられる。987個ものログがあるので片っ端から見ていくのは効率が悪い。何かしらのヒント探そう。

色：ログごとに色が違う。灰色や赤、黄、黒がある。
source：基本は第4オクテットが103,104がやり取りしているようだ。途中から105,254もある。

序盤(1~756)は103と104が通信を行っている。tcp,http。ここから色やsourceが変わっていく。いったん仕様や、用語を調べてみる。

知識(wirshark色規則, プロトコル, HTTP, TCP)

wirshark色規則

どうやら、表示→色付けルールで設定されたルールを確認できる模様。基本はプロトコルで分けられているようだがBad TCPを見るとやり取りによって色分けされている感じかな？Bad TCPめちゃくちゃ気になる。【Wireshark】色付けルール&パケット解析の見方 - (O+P)ut (mtioutput.com)

プロトコル

通信を行う上での約束事。通信を行う際はこれが必要。 https://wa3.i-3-i.info/word11.html

HTTP

通信プロトコルの一つ。webブラウザとwebサーバーとのプロトコル。ホームページのファイル受け渡しに使う。 https://wa3.i-3-i.info/word165.html

TCP

通信プロトコルの一つ。安全性重視。つまり、データがきちんと届くことを確認しながら通信する。欠点はスピードが遅い。TCPと対比されるのがUDP https://wa3.i-3-i.info/word19.html

　757で灰色が出てきた。TCP SYN/FIN。つまり、通信の開始か終了の申請みたいなのがこの通信で行われているのかな。Infoに[FIN,ACK]とあるので、相手のFINに応え、こっちも閉じると通信している。でも、FINが送られていないような。よく見たら先までいなかった105にいきなり104がFIN、ACKを送ったようだ。

知識(TCP通信のコントロールフラグ, TLS)

TCP通信のコントロールフラグ

終了や強制遮断などのフラグを表している。【初心者わかりやすく】TCP通信の確立と終了シーケンス | hirota.noの技術ブログ〜 It's all over the network. (hirotanoblog.com)

TLS

通信を暗号化して送受信する方法。SSLを標準化したものがTLS 基礎知識　SSL/TLSの仕組み (soumu.go.jp)

　そして、105が104にTLS通信とTCP通信が行われたのちに、[RST,ACK]が104から105に送られている。これがコネクトの強制遮断となり、ログが赤色になっている。そのあとは104から105に[SYN]が送られTCP通信が行われるようだ。しばらく105と104の間でTCPとTLS通信が交わされて、774から104と103のHTTPとTCP通信が再開された。そして、ブロードキャストを挟んで104と134がTCP,HTTP通信をし始めたところまた、105にいきなり104がFIN、ACKを送った。先のような展開がまた繰り広げられて。853,855でBad TCPが104から105に送られる。そして、また、先のような展開が起こっているようだ。
　ここから、104はある一定の通信を行うと105と異様な通信を行い始めるものなのではないかと考えた。そこで、4回ある異様な104と105の通信の開始位置前の104との通信を見ることで何かわかると考えた。
　・1回目　

No.757で灰色になっている。その2個前のログで103→104にHTTPを送っている。 encryptになっているので中身を見ても情報なし。
　・2回目

No.829。その２個前では134→104にHTTP通信がある。text/htmlが送られている。そして、下の方にLine-based text data: text/htmlに暗号化された、どこかの問題でflagになっていたような文字列を発見。要注意。 Gur synt vf cvpbPGS{c33xno00_1_f33_h_qrnqorrs}
　・3回目

No.936。2個前は103→104へのHTTP通信。1回目と同じ。
　・4回目

No.966。2個前は254→104へのHTTP通信。text/plainを送っている。平文なのでflagがそのままありそうと期待。Line-based text data: text/plainがnoneになっている。何もえれないようだ。こうなると怪しい2回目を探っていく。
　結論から言いますと何もわからなかった。HTTPを追跡してみたが、暗号方式などは記述されていなかった。writeupを見たところ、rot13を使用しているとのこと。理由を記述してあるサイトがなく、経験則からわかるものなのかどうなのか知りたい。HTTPの仕様なのだろうか。

考察

通信ログの解析を行った。実際GUIの見やすさがすごいと感じた。CUIとは適材適所な気がします。怪しい通信ログもこのように仕分けるのだと実践的に学べた。キャプチャをずっとしておくと、事後対応にも活かせるのだろうか？でも容量が足りなくなりそう。そこんところ調べていこうと思います。wireshark楽しい。

MacroHard WeakEdge

I've hidden a flag in this file. Can you find it?という言葉とともにpptmファイルが与えられている。まずは初手fileとstrigsコマンドで情報収集。

知識(xml)

xml

https://wa3.i-3-i.info/word1577.html

　fileコマンドではpowerPointだよと言っているがstringsではxmlと言っている。パワポ拡張子だけど記述方法がxmlということ？それとも拡張子が変更されているのだろうか？
　stringsコマンドの出力を見ていると階層構造の記述が多々見受けられる。
・ppt/presentation.xml
・ppt/slides/rels/slide46.xml.rels
・ppt/slides/slide1.xml～ppt/slides/slide58.xml
・ppt/slides/rels/slide1.xml.rels～ppt/slides/_rels/slide58.xml.rels(順番バラバラ)
(もっとあるのですがこのくらいに。) 途中で[Content_Types].xmlPKという記述もある。調べてもそこまで情報なし。なにかあるかもとbinwalkするとZip archive dataがいっぱい、処理しきれないのでいったん放置。
　ここでpptmファイルが渡された時のctfの定石を探しにggる。以下のようなサイトあり(パワポに埋められた文字を探せ CTF pptx - Qiita)。つまり、flagが図形などで隠されているかつ、動かすことができないような仕様になっている。今回の問題もこのような仕様になっている可能性はある。
　その前にいつも自分が利用しているパワポの拡張子はpptxということに気づく。pptmとpptxの違いってあるのか？

知識(pptmとpptxの違い)

pptmとpptxの違い

ちょうどこの疑問に答えてくれそうなサイトあり。pptmはマクロ付きパワポファイルにつくようだ。pptxではマクロは保存できないようだ。マクロを実行せずに開くためにはPowerPiont Viewerを用いるとよい。 pptmとはどんな拡張子？わかりやすく解説 Weblio辞書 https://wa3.i-3-i.info/word11545.html

という感じらしい。ダブルクリックで開かないのは正解だった(マクロの可能性あったから)。正常なパワポのstringsコマンド結果も知りたいので講義パワポであるpptxファイルをstringsとbinwalkしてみる。

.xmlとなっている。つまり、パワポはxml形式で記述されているのが正常であるようだ。初耳学。以降の実行結果を見ると階層構造になっている。これもパワポなら当たり前のようだ。次にbinwalk。これもZip archive dataがたくさんある。つまり、今までいろいろ悩んできたが怪しいとこはあまりない。
　とりあえずパワポに埋められたものを見ていくため、記事にあるようにpptmファイルをunzipしてみる。様々なフォルダやファイルが出てきた。すげー。(PowerPointのpptxはzipだった!? - スライドから画像・動画等を取り出す方法 - roombaの日記 (hatenablog.com))というようなサイトもあるようにパワポ資料をunzipできるのは知られているようだ。初耳学。ここから、flagを含んだファイルを探していく。grep picoCTF* -rl .と実行すると現在のディレクトリ内にpicoで始まる文字列を含んだファイルとフォルダを検索してくれる。-rlがフォルダ内も探してくれるオプションのようだ。hitなし。予想外。
　お手上げ。WriteUp(picoCTF2021 [Forengics] writeup - 好奇心の足跡 (kusuwada.com))を見たところflagが変換されているようだ。失念していた。簡単に手に入ると思い込んでいた。では、怪しいファイルやフォルダを探すのが大切。

知識(findとgrepコマンド)

findとgrepコマンド

findはファイルの名前からファイルを検索してくれる。 grepは検索対象のファイルから指定した文字列を含む行を表示する。検索でも使い方が違うので注意。

　よってfindで怪しいファイルを探す。find -name "*hid*"コマンドで検索一件ヒット（writeup読んだからこのコマンドが打てました。経験値って大切）ヒットしたファイルのcatは以下のようになっている。 "Z m x h Z z o g c G l j b 0 N U R n t E M W R f d V 9 r b j B 3 X 3 B w d H N f c l 9 6 M X A 1 f Q"。このヒットしたファイルはASCII textであるらしい。よって文字コードの変換で難読化されていると考えた。スペースは邪魔なので消す。 ZmxhZzogcGljb0NURntEMWRfdV9rbjB3X3BwdHNfcl96MXA1fQ これがbase64に見えるらしい。わからん。

知識(エンコード, デコード)

エンコード、デコード

データをほかの形式に変換することがエンコード。それを戻すのがデコードである。この時、データは何か定めていない。何かしらのデータを何かしらに変換することがエンコードのように思う。(例)URLエンコード、文字エンコード https://wa3.i-3-i.info/diff397data.html https://wa3.i-3-i.info/word135.html

今回は何かしらの文字がエンコードされている可能性が高い。

知識(文字コード, 文字エンコード)

文字コード、文字エンコード

コンピュータは0,1しか認識できない。つまり、数字を扱っている。よって「あ」という文字を何かしらの数字として認識している。その数値のことを文字コードという。文字コードは複数種類存在していることから、正しく文字コードを指定しなければ正しく読むことができない。また、その「文字」と「数値」を対応させている表のようなものがある。その表のことを「文字エンコード」と考えるとわかりやすい。そして、表は一つではなく複数の種類存在している(そりゃ、文字コードが複数あるからね。)。その表を切り替えることを文字エンコードと呼ぶこともある。例えば、0101010というものも文字エンコードするものによっては異なるものになる。 https://wa3.i-3-i.info/word1894.html https://step-learn.com/article/fundamental/001-char-encoding.html

　ここで、base64が使用されているかを知るのはそんな感じがするからなのかなぁ。CTFでは定石っぽい。base64デコードするとフラグゲット。

考察

パワポファイルからflagを探すことを行った。unzipできることを初めて知った。また、flagがそのまま書かれているというのは確率低いのが当たり前と思った方がよさそう。難読化、暗号化されているのが当たり前。不自然なファイルやフォルダを探すことというのはマルウェアを特定するときにも大切な考え方だと思おう。素直な攻撃者はいない。

Trivial Flag Transfer Protocol

　Figure out how they moved the flag.という言葉とともに、pcapngファイルが渡される。wirewharkを使って開いてみる。以前に扱った問題と異なり、色によるおかしなログはなさそう。添えられている言葉からして、flagを隠しながら通信をやっていたということだろうか。ログ数は10万を超えているので適当に見ていけない。今回使用されているプロトコルはARP,SSDP,TFTPの3種類。

知識(ARP, SSDP, TFTP)

ARP

IPアドレスからMACアドレスを調べる仕組みで使用するプロトコルだそうだ。 https://wa3.i-3-i.info/word174.html

SSDP

UPnP(ユニバーサルプラグアンドプレイ)対応機器を探すときのプロトコル。 https://wa3.i-3-i.info/word12619.html

TFTP

UDPを使ったFTP通信のプロトコル https://wa3.i-3-i.info/word12417.html

　では、ざっくり見ていこう。

まずinstructions.txtを11から12へwriterequest送っている。そして。11から12へデータパケット送信。VMwareでのwho11,12をお互いにする。
次に11から12へplanのreadrequestを送っている。
エラー。そのやり取りをもう一回。
そのごSSDP（11と12ではない）したのちまたwho12に。SSDPの途中に割り込んでいるような感じ。
また、11～12へplanのreadrequestを送る。12から11へデータパケット行く。acknowleredge
その後、11から12へprogram.debのreadrequestを送る。(送ると記述しているが正しくはread requestだった。つまり、データを要求するのが11、データを渡すのが12のような感じ)

知識(debフォーマット)

debフォーマット

Linuxディストリビューションで利用されるバイナリのパッケージ。つまり、このパッケージの中に使用するコマンドのファイルのようなものが詰まっているということですかね？

ここから、12が11へデータパケットブロックを送る。それをacknowledgeするを271回繰り返す。その間に一回who11のやり取りを行っている。
次に、11～12へpicture1.bmpのreadrequestを送っている。また、パケット送ると認証が1611回繰り返される。
次に、11～12へpicture2.bmpのreadrequestを送っている。また、パケット送ると認証が71443回繰り返される。
who12をはさんで11～12へpicture3.bmpのreadrequestを送っている。また、パケット送ると認証が2865回繰り返される。
ここで、309に色が違うような。

方針：bmp画像を作ってその中にflagある可能性。
理由：ブロック１にヘッダ情報とみられるBMも文字確認。コピペしていけば一応作れる？
送受信したファイル：instructions.txt, plan, program.deb, picture1.bmp, picture2.bmp, picture3.bmpの6個がやり取りされている。この中身にデータあるとにらんでいます。
[2023/08/08]

おはようございます。では続きということですが、なんともすんともできない。 writeup(picoCTF2021 [Forengics] writeup - 好奇心の足跡 (kusuwada.com))を読んでお勉強。まず、どのようなものがTFTPでやり取りされているかfile→export object→ TFTP...から見ることができるらしい。へー。

　writeUpではdebを解析する動きをしている。debってもしかして思っている以上に情報が詰まってるのかも。もう一度調べる。え、待って！どうやってこのファイルとか抽出するの？って思ってたら、先の見ているウィンドウのすべて保存で全部抽出することができるぞ！すっご！前日まですべてのパケット除いてコピペしていくのかと思って絶望してたんです！
　debファイルってどう扱えばいいかわからなかったけど、展開(https://urashita.com/archives/28834#Debian-3)や扱い方 (https://eng-entrance.com/linux-package-dpkg)を参考にできそう。今回は展開をしてみたいので展開していく。

知識(アーカイブ)

アーカイブ

保存しておきたいデータを圧縮して保存しておくこと。アーカイブとは | クラウド・データセンター用語集／IDCフロンティア (idcf.jp)

　よってdebファイルはアーカイブされた圧縮ライブラリといった感じのもの。なので、アーカイブを展開して、その中の圧縮されたものも展開する作業が入る。 ar vx <debファイル>で展開できる。(https://linuxcommand.net/ar/#x) tarも同じくアーカイブを展開するコマンド。圧縮のされ方に応じてコマンドも変えるのかな。(tar/zipコマンドで解凍・圧縮一覧まとめ（gz、zip、tar.xzなど） (uguisu.skr.jp))gz,xzがあったがそれぞれ異なるようだ。こうして圧縮されたものを展開したところ。controlや展開後の階層からこのパッケージはstrghideであると考えられる。

知識(strghide)

strghide

ステガノグラフィーという技術で画像や音声ファイルに情報を埋め込んだり、抽出することができる。魔術師見習いのノート (pied-piper.net)

　これを用いて与えられたbitmapからflagを抽出すればよいのか？他のファイルであるplanとinstructions.txtを見てからにする。全部英語で意味のある文にはなっていない。暗号化か難読化処理されているように思う。経験してきたのはROT13かbase64。webツールで変更してみる(ROT13暗号暗号化 / 復号化 Online - DenCode)。ROT13があたりっぽい。wiresharkにもROT13で表示する機能を見るとよく使用される手段のように思う。可読文字に直すことができた。

instructions.txtでは、TFTPは暗号する機能がないのでflagを隠ぺいする方法を探している様子。
planは何かのプログラムを使ったようだ。写真を確認とある。

　では、写真から情報を収集しにいく。steghide extract -sf picture1.bmpとするとパスフレーズを聞かれる。これは1,2,3どれでもそのようだ。パスフレーズなんてあったっけ？planかinstructionが怪しいよね。調べるとplanの中の1単語がpathpraseになっているようだ。気づけないなぁ。ひらめきも大切なようだ。これで3の方からflag.txtを手に入れることができた。(with ~という言葉が見つけられるっぽい。ヒントを見逃さないことが大切)

考察

wiresharkの使い方はまだまだいろいろ知ることが多そうだと感じた。また、writeupに少々頼りすぎている節がある。すぐに見るのではなく、技術を探すことをもう少し取り組む。画像の情報を隠す方法の新しいものを見たように思う。ヘッダ情報をいじる以外の方法を知ることができた。活かす。

ここから方針を変えてsolvesが1万人以上いる問題から解いていこうと思います。

Enhance!

Download this image file and find the flag.という言葉とともにsvg形式の何かがダウンロードされた。なんやこれ。
　初手、file,stringsで中身を見ていく。 stringsでは作られ方のようなプログラミングされたものが出てきた。bitmapとは構造が違うことがよくわかる。コードを眺めているが、図形のわりにコードが長いような気がする。もしかしたら、図形で隠されている可能性があるのかも。ずらしたり消したりするのが有効かもしれないと考えています。svgの書き方について調べてトライ。

知識(svg)

svg

前、bitmapで扱ったときに調べた時に画像には2種類あると書いてあった。bitmapと、違う種類の1だと思う。点で表すのではなく。ベクトルで表すもの。【超入門】SVGファイルって何？特徴と変換方法まとめ - RAKUS Developers Blog | ラクスエンジニアブログ

　調べたところtextの欄に書かれているものが表示されていないように思った。ここにflagあると考えた。パッと見てもp,i,c,o,C,T,Fという文字が浮かび上がている。不必要なとこを省いて出てきた。終了。でも表示はできない。何とかしてもいいかも。

考察

初めて触る構造とかだとやはりわかりにくいと感じた。今回難読化されていたらもっと時間はかかっていたと思う。

Lookey here

Attackers have hidden information in a very large mass of data in the past, maybe they are still doing it. Download the dataという言葉とともにtxtファイルが渡されている。こういう時は初手file,strings。stringsは大きくなりそうなのでまずは初めの100行だけ。ということでUNICODEのテキストファイルで何かしら可読文字がかかれているようだ。この中からflagを探す。さすがに読んでみても意味なさそう。grepみたいなコマンドで探すのがいいかも。 grep pico* anthem.flag.txtでビンゴ。

考察

大きいファイルということでできることが狭くなったような気もする。

Packets Primer

Download the packet capture file and use packet analysis software to find the flag.という言葉とともにpcapngファイルが渡された。9行しかないので激ムズと思ったがポチポチしてたらそれっぽいデータがあったのでおしまい。

[2023/08/09]

Redaction gone wrong

Now you DON’T see me. This report has some critical data in it, some of which have been redacted correctly, while some were not. Can you find an important key that was not redacted properly?という言葉とともにPDFファイルが渡された。flagが隠されているようだ。
安定の初手file,stringsコマンド。 PDFファイルということしかわからなさそう。文字列として簡単に抽出はできない。実際に見てみる。つまり、黒塗りされた下の部分にflagがあるのかな。もしかして、パワポみたいにunzipすることはできないかと考え、binwalkで埋め込まれたなにかがないかを探る。ありそう。よし、抽出しよう！binwalk -e Financial_Report_for_ABC_Labs.pdf --run-as=root 2つのファイルとそれらの.zlibファイルが手に入った。818Eと879C。879Cは文字化けしている感じ。展開すると0というファイル。おなじ文字化け。818Eの展開では0と60Eが手に入る。0を展開すると再び0と60E。60Eを展開すると0が出てくる。そして。60Eとそこから出てくる0は879Cと同じであるが818Eとそれから得られる0は何か書かれている。しかし、有力な手無し。
writeupを見てお勉強。(picoCTFのなんちゃってwrite_up - 日記)。黒塗り部分も選択できるようだ。なんてこった。選択したらできますね。

考察

深読みしすぎた。技術に頼りすぎて遠回りをしてしまったように思う。パワポでも図形を動かすことができるならunzipする必要もない時があるかもしれない。様々な技術を知って、最短で見つけられるようになりたいと思いました。

So Meta

Find the flag in this picture.という言葉とともに画像ファイルを渡された。初手file,stringsコマンド。 stringsコマンドの後ろにflagあり。終了。

知識(exiftool)

画像データにはメタデータという情報が格納された領域があるようだ。それを調べても出てくる。

考察

画像データや音声データにはヘッダーや今回のようにメタデータを格納している領域が存在している。そこの確認を行うのも情報を得るという点でよいと思います。

[2023/08/11]

shark on wire 1

We found this packet capture. Recover the flag.という言葉とともにpcapngファイルが渡された。まずは文字列検索でpicoCTFから始まるものを探してみる。 ctrl+fで文字列入力にして、picoで検索。 No.55でUpicoという文字列がUDP payloadで送られている。他のUDPで送られているDataのところを確認すると10.0.0.2から10.0.0.13に送られているデータを集めるとp,i,c,o,C,T,Fになっているので、表示フィルタをip.src ==10.0.0.2 and ip.dst == 10.0.0.13として検索集めていくとpicoCTF{N0t_a_fLag}。ん？not a flag?案の定違っていた。だまされた感じですね。 10.0.0.2から13以外に送られているものを探してみる。12が似ている。 ip.src ==10.0.0.2 and ip.dst == 10.0.0.12で検索してDataの文字を集めるとビンゴ。

考察

実際picoと調べてその周辺を調べてたらそれっぽいのがあったので良かったが、本来だったらp,i,c,oと分けて検索した方が良い時もありそう。一回でflagをやり取りせず、分けて送信することでflagをわかりにくする方法を知った。

extensions

This is a really weird text file TXT? Can you find the flag?という言葉とともにflag.txtというファイルを渡された。初手file,stringsコマンドで情報収集していこうと思う。
これはつまり、拡張子はtxtとなっているが実際はpng形式のデータなのではないだろうか。拡張子を.pngに変更する。mv flag.txt flag.pngとして、画像を見るとflagが描かれている。終了

考察

extensionsが拡張子という意味のようで、拡張子に注目させたかったようだ。

What Lies Within

There's something in the building. Can you retrieve the flag?という言葉とともにpng形式のファイルを渡された。 png画像なのでまず見てみましょう。建物の画像。binwalkで埋め込まれているかを確認、ステガノグラフィーによる埋め込みの可能性もある。展開していったが有力なデータは見当たらなかった。 (PNGを読む #Go - Qiita) そもそもpng画像にはzlibが埋め込まれているようだ。次にステガノグラフィーを疑っていこう。

[2023/08/12]

以前扱ったものを試してみる。
しかし、サポートしてない。埋め込まれていないってこと？ギブアップ。writeup見てみる。 (picoCTF-2019-writeup/Forensics/What Lies Within/README.md at master · kevinjycui/picoCTF-2019-writeup · GitHub) オンラインで調べる方法があるようだ。実際にデコードしてみると手に入った。ステガノグラフィーは複数の方法があるようだ。

考察

方針は間違っていなかったが、ステガノグラフィーは予想以上に奥が深そうに感じた。時間があるときに調べたいと思います。

　また、ここで一万以上のsolvesは解いた。以降は一万以下のsolvesをsolvesが高いものから解いていきたいと思います。

[2023/08/13]

Sleuthkit Intro

Download the disk image and use mmls on it to find the size of the Linux partition. Connect to the remote checker service to check your answer and get the flag. Note: if you are using the webshell, download and extract the disk image into /tmp not your home directory.

Download disk image
Access checker program: nc saturn.picoctf.net 64605

という言葉とともに.gz形式のファイルが渡された。
　方向性があまり見えていない。mmlsについて調べてみる。

知識(mmls)

mmls

ボリュームシステムのパーティションレイアウト情報を表示する。 mmls | Forensicist

　あんまりピンっと来ていない。触れたことのないやつですね。落ち着いて初手fileコマンド。
圧縮されているので展開してみるのがいいかも。.gzの圧縮展開についてよいサイトがあったのでそこで調べた(Linuxでの圧縮・解凍方法をまとめた(.gzのみ)。)。よってgunzip disk.img.gzを実行して展開。出てきたファイル(file disk.img)に対して、fileコマンド。

知識(.img)

imgファイル

IMGファイル拡張子 - IMG形式とは何か、どのように開くか

というわけで、imgファイルからディスクの中身を見ていこうと思う。mmlsの仕様を確認して、mmls -B disk.imgを実行。
　これでlinux partationのサイズはわかったのではないでしょうか？
通信を行ってみる。通信をするとサイズが聞かれるのでDescriptionがlinuxの行のlengthの値を入力。flagゲット。

考察

　今回imgファイルの中をmmlsで見てみた。パーテーションがどのようになっているのかを確認した。これで怪しい領域を探していくのだろうか？ひとまずforensicらしい問題でした。

[2023/08/14]

[2024/01/23]

PcapPoisoning

How about some hide and seek heh? Download this file and find the flag. かくれんぼですか。よくわからん。まずはpcapファイルなので開いてみる。
よく目に入ってくるのはFTP-DATAとTCPである。

知識(FTP)

FTP

(FTP) つまり、データを転送するときに使用するプロトコルということかな。暗号化されないらしいので何かしら情報が得られそう。

値を見ていくとgc2VjcmV0OiBwaWNvQ1RGeというものが多く記載されている。気になるがわからない。cyberchefでもなんともなかった。ずっと下に行くと色が変わる。
Infoを見るとTCP Retransmissionというものが行われている。

知識(TCP Retransmission)

TCP Retransmission

(【Wireshark】TCP解析（Retransmission/Dup ACK など）) を参考にしました。要するに相手に送られたかがわからないと次に進めないので再送しているということだと思う。

ここで気が付いたが、time順にした方がいいですね。そうするとFTPとTCP Retransmissionは同時刻に起こっている。ここで再送されたものを見ているときに0.101836の時刻にSource:172.16.0.2、Destination:10.253.0.6で行われている通信を開くとそのままflagあり。偶然見つかった感じで少し納得がいっていない。

考察

writeUpを確認する。(CTF Writeup: picoCTF 2023),(picoCTF 2023 writeup)この二つを確認してシナリオを自身で考えてみた。flagのやり取りをしている2つのPCはNo4でユーザーとパスを要求していることからここで認証を行っているユーザーだと考えられる。 (FTP - データのやり取りに使われるプロトコル)を参考にするとやはり認証が行われているようだ。ポートの20と21にも役割が固定されているようだ。それ以外はほかの人がFTPでやり取りしているせいで、flagをやり取りしているログが分かりにくくなっている。つまり、ポイズニングされてしまっているというのが問題の題名につながるように思った。

hideme

Every file gets a flag. The SOC analyst saw one image been sent back and forth between two people. They decided to investigate and found out that there was more than what meets the eye here.
画像からflagを得る問題。
まず不審なファイルを見たらfileとstringsコマンドを行う。

└─# file flag.png
flag.png: PNG image data, 512 x 504, 8-bit/color RGBA, non-interlaced

└─# strings flag.png
~
secret/UT
secret/flag.pngUT
~

という謎の文字列あり。これがflagに関係していそう。しかも2回この文字列がある。
次に行うのはbinwalkですかね。

└─# binwalk flag.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 512 x 504, 8-bit/color RGBA, non-interlaced
41            0x29            Zlib compressed data, compressed
39739         0x9B3B          Zip archive data, at least v1.0 to extract, name: secret/
39804         0x9B7C          Zip archive data, at least v2.0 to extract, compressed size: 2997, uncompressed size: 3152, name: secret/flag.png
43036         0xA81C          End of Zip archive, footer length: 22

やっぱり何かしらのものが埋め込まれてますね。抽出して、確認。その中に画像があってflagあり。終了。

[2024/01/30]

Wireshark twoo twooo two twoo...

この問題はライトアップ見ないで頑張りたいと意気込んでおります。 Can you find the flag?という言葉とともにpcapngをいただきました。なんぼあってもいいですね。さてまず、どんな通信が行われているか。統計、プロトコル階層統計から探る。UDPは少々、TCPが良く利用され、HTTPも多いイメージ。次に、ファイルからオブジェクトをエクスポートでHTTPを選択、text/htmlタイプのファイル名にflagがあり、終了と思ったがどれも値が異なり、正解でもなかった。

知識(DNS, GQUIC)

DNS

IPアドレスとドメイン名を紐づけるシステムのこと https://wa3.i-3-i.info/word1287.html

GQUIC

GoogleのQUICのことだそうだ。 UDP上に用意したプロトコルでHTTPを行っている。 Quicとは何か？ - Qiita

ここでpicoCTFで文字列検索をかけてみた。そうすると複数のflagらしき形式の文字列発見。あてずっぽうで一つ打ってみる。incorrect！ですよね。ここから正しいのを見つけないといけないようだ。 Source:18.217.1.57 Destination:192.168.38.104 HTTP 263 HTTP/1.0 200 OK (text/html)といパケットでpicoCTFのような文字列が送られている。
ここで偽のpicoCTFflagを送信しているアドレスに注目する。フィルタでip.addr == 18.217.1.57を用いて検索。はじめのhttp通信で送られてきたtext/htmlは何か書いてあった。「The official Red's Shrimp and Herring website is still under construction. Please check back later!」。Red's Shrimp and Herring websiteを後々確認せよということわかった。見てみると、DNS プロトコルでZnR3X2Rl.reddshrimpandherring.comのような先の文に関係しそうな文字列が含まれていた。そこに注目していくと、

cGljb0NU.reddshrimpandherring.com
RntkbnNf.reddshrimpandherring.com
M3hmMWxf.reddshrimpandherring.com
ZnR3X2Rl.reddshrimpandherring.com
YWRiZWVm.reddshrimpandherring.com
fQ==.reddshrimpandherring.com

一番下のURLを見た時にピンッと来ました。これBase64でエンコードされている文字が含まれているのではないかと。「.reddshrimpandherring.com」の接頭語が何かしらをエンコードしたものになっていると考え、それらをつなぎ合わせて、cyberchefでbase64したらflagゲット。終了。

参考

(picoCTF 2021 Wireshark twoo twooo two twoo...)を見た。もっとスマートにwiresharkを使っていた。C2サーバに送られているような通信だという視点も納得。

who is it

Someone just sent you an email claiming to be Google's co-founder Larry Page but you suspect a scam. Can you help us identify whose mail server the email actually originated from? Download the email file here. Flag: picoCTF{FirstnameLastname}

疑っているようです。メールに添付ファイルあり。そして、onionmailということで身元隠している。怪しいですね。あらかた見ましたが、名前まではわからないという感じ。writeup見てしまいました。(CTF Writeup: picoCTF 2023)そうするとipアドレスから割り出していた。ipアドレスには気づいていましたが、そこから割り当てることもできるのがびっくり。whoisコマンドで情報を出しpersonというとこで名前が分かる。終了。

Sleuthkit Apprentice

Download this disk image and find the flag. Note: if you are using the webshell, download and extract the disk image into /tmp not your home directory.

imgファイルを渡されたのが初めてで初手が分からんということで少し調べました。(Forensics入門（CTF）)

イメージディスクを与えられたとき、fileとmmlsコマンドを初手で行うのが良いと思うので、
実行。

└─# file disk.flag.img
disk.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0xc,223,19), startsector 2048, 204800 sectors; partition 2 : ID=0x82, start-CHS (0xc,223,20), end-CHS (0x16,111,25), startsector 206848, 153600 sectors; partition 3 : ID=0x83, start-CHS (0x16,111,26), end-CHS (0x26,62,24), startsector 360448, 253952 sectors

└─# mmls disk.flag.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000206847   0000204800   Linux (0x83)
003:  000:001   0000206848   0000360447   0000153600   Linux Swap / Solaris x86 (0x82)
004:  000:002   0000360448   0000614399   0000253952   Linux (0x83)

ちなみにファイルシステムは

└─# fsstat -t disk.flag.img -o 2048
ext4

である。以上から、パーテーションは3つに分かれているようだ。 2つ目はスワップ空間なので、オフセット2048と360448から始まるところを調べようと思う。 (スワップについて)

└─# fls disk.flag.img -o 2048
d/d 11: lost+found
r/r 12: ldlinux.sys
r/r 13: ldlinux.c32
r/r 15: config-virt
r/r 16: vmlinuz-virt
r/r 17: initramfs-virt
l/l 18: boot
r/r 20: libutil.c32
r/r 19: extlinux.conf
r/r 21: libcom32.c32
r/r 22: mboot.c32
r/r 23: menu.c32
r/r 14: System.map-virt
r/r 24: vesamenu.c32
V/V 25585:      $OrphanFiles

└─# fls disk.flag.img -o 360448
d/d 451:        home
d/d 11: lost+found
d/d 12: boot
d/d 1985:       etc
d/d 1986:       proc
d/d 1987:       dev
d/d 1988:       tmp
d/d 1989:       lib
d/d 1990:       var
d/d 3969:       usr
d/d 3970:       bin
d/d 1991:       sbin
d/d 1992:       media
d/d 1993:       mnt
d/d 1994:       opt
d/d 1995:       root
d/d 1996:       run
d/d 1997:       srv
d/d 1998:       sys
d/d 2358:       swap
V/V 31745:      $OrphanFiles

オフセットが360448から始まる方の中にrootやhomeディレクトリがあるので、ここにflagらしきものがないかを確認。

└─# fls -r disk.flag.img 451 -o 360448

└─# fls -r disk.flag.img 1995 -o 360448
r/r 2363:       .ash_history
d/d 3981:       my_folder
+ r/r * 2082(realloc):  flag.txt
+ r/r 2371:     flag.uni.txt

以上の結果からroot配下のディレクトリが怪しそう。flag.uni.txtを└─# icat disk.flag.img 2371 -o 360448で見てみるとflagゲット。

Disk, disk, sleuth!

Use srch_strings from the sleuthkit and some terminal-fu to find a flag in this disk image: dds1-alpine.flag.img.gz ということで、イメージファイルを受け取った。srch_strings というコマンドを使うのかな？

トリマ、自身を貫く。

└─# file dds1-alpine.flag.img
dds1-alpine.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0x10,81,1), startsector 2048, 260096 sectors

└─# mmls dds1-alpine.flag.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000262143   0000260096   Linux (0x83)

パーテーションは一つしかないようだ。

└─# fls dds1-alpine.flag.img -o 2048
d/d 10161:      home
d/d 11: lost+found
r/r 12: .dockerenv
d/d 2033:       bin
d/d 8129:       boot
d/d 6097:       dev
d/d 16257:      etc
d/d 28449:      lib
d/d 22353:      media
d/d 24385:      mnt
d/d 26417:      opt
d/d 24386:      proc
d/d 26418:      root
d/d 24387:      run
d/d 26419:      sbin
d/d 20321:      srv
d/d 20322:      sys
d/d 20323:      tmp
d/d 24388:      usr
d/d 20324:      var
V/V 32513:      $OrphanFiles

rootやhome見てもファイルなし。
指示通りsrch_stringsを使ってみる。可読文字列を表示するので、grepを用いて検索をかける。 └─# srch_strings dds1-alpine.flag.img | grep picoCTFでflagゲット。

Disk, disk, sleuth! II

All we know is the file with the flag is named down-at-the-bottom.txt... Disk image: dds2-alpine.flag.img.gz 初手はお決まり、

└─# file dds2-alpine.flag.img
dds2-alpine.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0x10,81,1), startsector 2048, 260096 sectors

└─# mmls dds2-alpine.flag.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000262143   0000260096   Linux (0x83)

前回と同じでパーテーションは1つだけ。

└─# fls dds2-alpine.flag.img -o 2048
d/d 26417:      home
d/d 11: lost+found
r/r 12: .dockerenv
d/d 20321:      bin
d/d 4065:       boot
d/d 6097:       dev
d/d 2033:       etc
d/d 8129:       lib
d/d 14225:      media
d/d 16257:      mnt
d/d 18289:      opt
d/d 16258:      proc
d/d 18290:      root
d/d 16259:      run
d/d 18292:      sbin
d/d 12222:      srv
d/d 16260:      sys
d/d 18369:      tmp
d/d 12223:      usr
d/d 14229:      var
V/V 32513:      $OrphanFiles

パーテーションの構造も酷似。 homeとrootを見てみる。

└─# fls -r dds2-alpine.flag.img 18290 -o 2048
r/r 18291:      down-at-the-bottom.txt

rootにありそう。

└─# icat dds2-alpine.flag.img 18291 -o 2048
   _     _     _     _     _     _     _     _     _     _     _     _     _
  / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \
 ( p ) ( i ) ( c ) ( o ) ( C ) ( T ) ( F ) ( { ) ( f ) ( 0 ) ( r ) ( 3 ) ( n )
  \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/
   _     _     _     _     _     _     _     _     _     _     _     _     _
  / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \
 ( s ) ( 1 ) ( c ) ( 4 ) ( t ) ( 0 ) ( r ) ( _ ) ( n ) ( 0 ) ( v ) ( 1 ) ( c )
  \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/
   _     _     _     _     _     _     _     _     _     _     _
  / \   / \   / \   / \   / \   / \   / \   / \   / \   / \   / \
 ( 3 ) ( _ ) ( f ) ( f ) ( 2 ) ( 7 ) ( f ) ( 1 ) ( 3 ) ( 9 ) ( } )
  \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/   \_/

となっている。これを成形したらいいのかな？でけた。終了。

[2024/02/15]

[2024/02/16]

Pitter, Patter, Platters

'Suspicious' is written all over this disk image. Download suspicious.dd.sda1 ということで、イメージファイルを渡された。

└─# file suspicious.dd.sda1
suspicious.dd.sda1: Linux rev 1.0 ext3 filesystem data, UUID=fc168af0-183b-4e53-bdf3-9c1055413b40 (needs journal recovery)

だそうです。今までとは違うようだ。一つのパーテーションを渡された感じ？

└─# fls suspicious.dd.sda1
d/d 11: lost+found
d/d 2009:       boot
d/d 4017:       tce
r/r 12: suspicious-file.txt
V/V 8033:       $OrphanFiles

怪しいのがあるので見てみようと思う。

└─# fls suspicious.dd.sda1 12
Error extracting file from image (ext2fs_dir_open_meta: Error reading directory contents: 12
)

なにやら見れないようだ。

└─# icat suspicious.dd.sda1 12
Nothing to see here! But you may want to look here -->

中身的には覗かれるのは予想済みの様子。もっと詳しく。見てみる。

└─# fls -r suspicious.dd.sda1
d/d 11: lost+found
d/d 2009:       boot
+ d/d 2010:     grub
++ r/r 2013:    e2fs_stage1_5
++ r/r 2014:    fat_stage1_5
++ r/r 2015:    ffs_stage1_5
++ r/r 2016:    iso9660_stage1_5
++ r/r 2017:    jfs_stage1_5
++ r/r 2018:    minix_stage1_5
++ r/r 2019:    reiserfs_stage1_5
++ r/r 2020:    stage1
++ r/r 2021:    stage2
++ r/r 2022:    stage2_eltorito
++ r/r 2023:    ufs2_stage1_5
++ r/r 2024:    vstafs_stage1_5
++ r/r 2025:    xfs_stage1_5
++ r/r 2026:    menu.lst
+ r/r 2011:     core.gz
+ r/r 2012:     vmlinuz
d/d 4017:       tce
+ r/r 4018:     mydata.tgz
+ d/d 4019:     optional
++ r/r 4022:    openssh.tcz.dep
++ r/r 4023:    gcc_libs.tcz.md5.txt
++ r/r 4024:    gcc_libs.tcz
++ r/r 4025:    openssl-1.0.0.tcz.md5.txt
++ r/r 4026:    openssl-1.0.0.tcz
++ r/r 4027:    openssh.tcz.md5.txt
++ r/r 4028:    openssh.tcz
++ r/r 4029:    nano.tcz.dep
++ r/r 4030:    ncurses.tcz.dep
++ r/r 4031:    ncurses-common.tcz.md5.txt
++ r/r 4032:    ncurses-common.tcz
++ r/r 4033:    ncurses.tcz.md5.txt
++ r/r 4034:    ncurses.tcz
++ r/r 4035:    nano.tcz.md5.txt
++ r/r 4036:    nano.tcz
++ r/r 4037:    nginx.tcz.dep
++ r/r 4038:    pcre.tcz.dep
++ r/r 4039:    bzip2-lib.tcz.md5.txt
++ r/r 4040:    bzip2-lib.tcz
++ r/r 4041:    pcre.tcz.md5.txt
++ r/r 4042:    pcre.tcz
++ r/r 4043:    nginx.tcz.md5.txt
++ r/r 4044:    nginx.tcz
++ r/r 4045:    fuse.tcz.md5.txt
++ r/r 4046:    fuse.tcz
++ r/r 4047:    libdnet.tcz
++ r/r 4048:    open-vm-tools.tcz
++ r/r 4049:    open-vm-tools-modules-3.8.13-tinycore.tcz
++ r/r 4050:    libtirpc.tcz.md5.txt
++ r/r 4051:    libtirpc.tcz
++ r/r 4052:    glib2.tcz.dep
++ r/r 4053:    libffi.tcz.md5.txt
++ r/r 4054:    libffi.tcz
++ r/r 4055:    glib2.tcz.md5.txt
++ r/r 4056:    glib2.tcz
+ d/d 4020:     ondemand
+ r/r 4021:     onboot.lst
r/r 12: suspicious-file.txt
V/V 8033:       $OrphanFiles

特段怪しいのはない。
ここで、今まではディスクイメージを渡されていたので、mmlsコマンドやautopsyが使えないのが難しい。他の探る方法はないかと思い、(Linuxディスク関連コマンドまとめ)を参考にする。 └─# dumpe2fs suspicious.dd.sda1や└─# e2fsck -n suspicious.dd.sda1を使用したが、あまり有力と思われる情報はないように思った。 autopsyを拡張子の読み込みを変更したらsda1でも読み込むことができた。これが、その中身、怪しいものはないようにも思う。中身を見ていて思ったこと。 * /Carved Files/1には/tec/mydata.tgzと同じような構造のディレクトリが4つある。 * /Carved Files/1にあるのは削除されているディレクトリである。 * また、その4つの違いは/etc/hostnameがboxとyVMがある。 * また、/tce/mydata.tgz/mydata.tar/usr/local/etcにはnginxとsshというディレクトリがある。 * /tce/mydata.tgz/mydata.tar/home/tc/.ash_historyに実行されたコマンド履歴がある。

また、/tce/mydata.tgz/mydata.tar/opt/shutdown.shには以下のような記述があり。

#!/bin/busybox ash
. /etc/init.d/tc-functions
useBusybox
# put user shutdown commands here
# If no backup of home was done then loop through valid users to clean up.
if [ ! -e /tmp/backup_done ] || ! grep -q "^home" /opt/.filetool.lst; then
  awk 'BEGIN { FS=":" }  $3 >= 1000 && $1 != "nobody" { print $1 }' /etc/passwd > /tmp/users
  while read U; do
    while read F; do
      TARGET="/home/${U}/$F"
      if [ -d "$TARGET" ]; then
        rm -rf "$TARGET"
      else
        if [ -f "$TARGET" ]; then
          rm -f "$TARGET"
        fi
      fi
    done < /opt/.xfiletool.lst      
  done < /tmp/users

/tep/usersが存在するが、このsda1には見当たらない。

(bootsync.shについて)bootsync.shに
boxユーザーについて書かれている。boxユーザーを見てみようと思う。お手上げ、writeup見る。 (picoCTF 2020 Mini-Competition)。
めちゃくちゃ要約するとslack領域というものが存在しているようだ。autopsyのデフォルトではこれが非表示になっていた。

知識(slack space)

slack space

(slack spaceから機密情報を暴いてやる！！)を参考にしました。つまり、ブロック単位(セクタ)でファイルを管理している。その時に、ファイルサイズがセクタやクラスタ未満のものを扱うと余っているとセクタやクラスタに使われない空きのようなとこができる。ここがslack spaceということらしい。ここの機能がデータ復元の糸口になるようです。

/tool/option/slack領域のところを見ると確かに非表示にするようになっている。非表示を解除して適応すると、新しくファイルが表示された。
そこにflagがある。flagが反転されているので、ツール(オンラインリバース文字列)を用いて反転すれば終了。

考察

autopsyを用いることが決め手になることが多いのはわかってきたが、設定的に知らないことがあると今回のような問題には対処できない。
徐々に知っていくのがいいと思う。

Operation Orchid

Download this disk image and find the flag.
シンプルなことしか書かれていませんね。まずはいつもの初手。

└─# file disk.flag.img
disk.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0xc,223,19), startsector 2048, 204800 sectors; partition 2 : ID=0x82, start-CHS (0xc,223,20), end-CHS (0x19,159,6), startsector 206848, 204800 sectors; partition 3 : ID=0x83, start-CHS (0x19,159,7), end-CHS (0x32,253,11), startsector 411648, 407552 sectors

└─# mmls disk.flag.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000206847   0000204800   Linux (0x83)
003:  000:001   0000206848   0000411647   0000204800   Linux Swap / Solaris x86 (0x82)
004:  000:002   0000411648   0000819199   0000407552   Linux (0x83)

以前に見たことありそうな形。後々autopsyを使うが、まずはコマンドで。

└─# fls disk.flag.img -o 2048
d/d 11: lost+found
r/r 12: ldlinux.sys
r/r 13: ldlinux.c32
r/r 15: config-virt
r/r 16: vmlinuz-virt
r/r 17: initramfs-virt
l/l 18: boot
r/r 20: libutil.c32
r/r 19: extlinux.conf
r/r 21: libcom32.c32
r/r 22: mboot.c32
r/r 23: menu.c32
r/r 14: System.map-virt
r/r 24: vesamenu.c32
V/V 25585:      $OrphanFiles

└─# fls disk.flag.img -o 411648
d/d 460:        home
d/d 11: lost+found
d/d 12: boot
d/d 13: etc
d/d 81: proc
d/d 82: dev
d/d 83: tmp
d/d 84: lib
d/d 87: var
d/d 96: usr
d/d 106:        bin
d/d 120:        sbin
d/d 466:        media
d/d 470:        mnt
d/d 471:        opt
d/d 472:        root
d/d 473:        run
d/d 475:        srv
d/d 476:        sys
d/d 2041:       swap
V/V 51001:      $OrphanFiles

上の方は以前のやつだとあまり惹かれるものはなさそう。下だと、homeかrootあたりがまずは怪しい。

└─# fls -r disk.flag.img 472 -o 411648
r/r 1875:       .ash_history
r/r * 1876(realloc):    flag.txt
r/r 1782:       flag.txt.enc

怪しいのはある。

└─# icat disk.flag.img 1782 -o 411648
Salted__S�+%���+�O��k�ђ(A����c��
                                @]ԣ
L�ޢȤ7� ���؎$�'%

└─# icat disk.flag.img 1876 -o 411648
           -0.881573            34.311733

そんな簡単ではないよね。

└─# srch_strings disk.flag.img | grep pico
ffffffff816989a0 t pirq_pico_get
ffffffff816989c0 t pirq_pico_set
ffffffff824640e2 t pico_router_probe
application/x-sega-pico-rom
picoJava,

知ってる知ってるｗないよね。

└─# fsstat -t disk.flag.img -o 411648
ext4

今回はこっちのファイルシステムのようだ。先のicatの時にSalted__Sという文字列がある。これを調べるとOpenSSLを用いた暗号化の時に現れるようだ。(OpenSSLで共通鍵暗号を使う場合の鍵の指定)
そして、autopsyで/img_disk.flag.img/vol_vol4/root/.ash_historyの履歴を見ると

touch flag.txt
nano flag.txt 
apk get nano
apk --help
apk add nano
nano flag.txt 
openssl
openssl aes256 -salt -in flag.txt -out flag.txt.enc -k unbreakablepassword1234567
shred -u flag.txt
ls -al
halt

暗号化が行われている。(【Linux】 OpenSSLでファイルの暗号と復号する方法)より、-kは昔の書き方で今は-passのようにするのだそう。パスワードを指定。(OpenSSLで共通鍵暗号を使う場合の鍵の指定) で-saltについても触れられていた。これ復号すればいいんとちゃうか？先ほどのサイトを参考にして、└─# openssl enc -d -aes256 -pass pass:unbreakablepassword1234567 -in flag.txt.encをしたらflagゲット。意外と簡単だと思った。

advanced-potion-making

Ron just found his own copy of advanced potion making, but its been corrupted by some kind of spell. Help him recover it!ということで、よくわからないファイルを渡された。
まずは初手いつものやつをやる。

└─# file advanced-potion-making
advanced-potion-making: data

└─# strings advanced-potion-making
IHDR
sRGB
gAMA
        pHYs
v9IDATx^
(>Zv
e2>|

data形式でstringsでもflagっぽいのは特になかった。しかし、stringsコマンドの最初に出てきたIHDRについて調べてみた。(PNGを読む)PNG形式の話かもしれない。今までの感覚からするとhexdumpを行うのが良いと思った。

└─# hexdump -v -C advanced-potion-making |head -n 10
00000000  89 50 42 11 0d 0a 1a 0a  00 12 13 14 49 48 44 52  |.PB.........IHDR|
00000010  00 00 09 90 00 00 04 d8  08 02 00 00 00 04 2d e7  |..............-.|
00000020  78 00 00 00 01 73 52 47  42 00 ae ce 1c e9 00 00  |x....sRGB.......|
00000030  00 04 67 41 4d 41 00 00  b1 8f 0b fc 61 05 00 00  |..gAMA......a...|
00000040  00 09 70 48 59 73 00 00  16 25 00 00 16 25 01 49  |..pHYs...%...%.I|
00000050  52 24 f0 00 00 76 39 49  44 41 54 78 5e ec fd 61  |R$...v9IDATx^..a|
00000060  72 e3 4c 94 a6 59 ce 16  6a fe 76 cd fe 57 d7 dd  |r.L..Y..j.v..W..|
00000070  5b 18 45 e9 4b 8a 7a 28  d1 9d 20 48 07 a9 63 76  |[.E.K.z(.. H..cv|
00000080  ac 2d 2b 3e bf af 5f 07  18 01 82 d7 b2 f3 ff f3  |.-+>.._.........|
00000090  ff fc 7f ff 7f 00 00 00  00 00 00 00 4b 18 58 02  |............K.X.|

.PB形式のようだ？PNGではないの？いったんPNG拡張子をつけてみる。(マジックナンバーまとめ)
やはり、形式がだめ。編集してみる。

└─# hexdump -v -C advanced-potion-making.png |head -n 10
00000000  89 50 4e 47 0d 0a 1a 0a  00 12 13 14 49 48 44 52  |.PNG........IHDR|

これでもまだ、駄目のようです。(イメージヘッダ(Image header、IHDR))シグネチャの後ろChunk Dataは常に13(0d)だそうなのでそこも編集してみる。

└─# hexdump -v -C advanced-potion-making.png |head -n 10
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|

まっかっか。他もいじればいいのかな？

└─# hexdump -v -C advanced-potion-making.png
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 09 90 00 00 04 d8  08 02 00 00 00 04 2d e7  |..............-.|
00000020  78 00 00 00 01 73 52 47  42 00 ae ce 1c e9 00 00  |x....sRGB.......|
00000030  00 04 67 41 4d 41 00 00  b1 8f 0b fc 61 05 00 00  |..gAMA......a...|
00000040  00 09 70 48 59 73 00 00  16 25 00 00 16 25 01 49  |..pHYs...%...%.I|
00000050  52 24 f0 00 00 76 39 49  44 41 54 78 5e ec fd 61  |R$...v9IDATx^..a|

この構造から、

ファイルシグネチャ
IHDR
sRGB
gAMA
pHYs
IDAT

となっているようだが、不審なことはない。お手上げ、writeUpを見てみよう。 (picoCTF picoGym Practice Challenges WriteUp その3)ステガノグラフィーを考えるとよいそうだ。赤を無くせばよさそう。Stegsolveを使ってみたいので使ってみる。(スペクトログラムとステガノグラフィー)扱いにくいｗ(CTFにおけるステガノグラフィ入門とまとめ)にあるhttps://georgeom.net/StegOnline/upload(StegOnline)に入れる方が簡単である。色彩を変えたらフラグゲット。

考察

画像フォーマットを変えることまではよかったが、ステガノグラフィーを忘れていた。binwallk以外にも抽出方法があることを忘れない。

like1000

This .tar file got tarred a lot. .tar拡張子のものが渡された。圧縮されているので解凍してみる。

└─# tar -xvf 1000.tar
999.tar
filler.txt

└─# cat filler.txt
alkfdslkjf;lkjfdsa;lkjfdsa

└─# tar -xvf 999.tar
998.tar
filler.txt

└─# cat filler.txt
alkfdslkjf;lkjfdsa;lkjfdsa

ここから、filter.txtは同じようだ。しかし、圧縮されているものは999回圧縮されているようだ。そんなにコマンド打ちたくない。bashでのプログラムを書いた。

知識(bashプログラミング)

bashプログラミング

(bash書き方基本) (bashでの算術演算) (for文構文)

#!/usr/bin/bash

kaku="tar"
number=1000
for i in `seq 999`
do
filename=$((number--)).${kaku}
tar -xvf ${filename}
rm ${filename}
done
exit 0

これで2.tarか1.tarにまで解凍できるので、あとは微調整するとpngが手に入る。flagが書かれているので、終了。

WhitePages

I stopped using YellowPages and moved onto WhitePages... but the page they gave me is all blank!

└─# strings whitepages.txt

なぜが空白が出てくる。なにかは書かれているのだろうか？

└─# hexdump -v -C whitepages.txt
00000000  e2 80 83 e2 80 83 e2 80  83 e2 80 83 20 e2 80 83  |............ ...|
00000010  20 e2 80 83 e2 80 83 e2  80 83 e2 80 83 e2 80 83  | ...............|
00000020  20 e2 80 83 e2 80 83 20  e2 80 83 e2 80 83 e2 80  | ...... ........|
00000030  83 e2 80 83 20 e2 80 83  e2 80 83 20 e2 80 83 20  |.... ...... ... |
00000040  20 20 e2 80 83 e2 80 83  e2 80 83 e2 80 83 e2 80  |  ..............|
00000050  83 20 20 e2 80 83 20 e2  80 83 e2 80 83 20 e2 80  |.  ... ...... ..|
00000060  83 20 20 e2 80 83 e2 80  83 e2 80 83 20 20 e2 80  |.  .........  ..|
00000070  83 20 20 e2 80 83 20 20  20 20 e2 80 83 20 e2 80  |.  ...    ... ..|
00000080  83 e2 80 83 e2 80 83 e2  80 83 20 20 e2 80 83 20  |..........  ... |
00000090  e2 80 83 20 e2 80 83 20  e2 80 83 e2 80 83 e2 80  |... ... ........|
000000a0  83 20 e2 80 83 e2 80 83  e2 80 83 20 20 e2 80 83  |. .........  ...|
000000b0  e2 80 83 e2 80 83 e2 80  83 e2 80 83 20 e2 80 83  |............ ...|
000000c0  20 e2 80 83 e2 80 83 e2  80 83 e2 80 83 e2 80 83  | ...............|
000000d0  20 e2 80 83 20 e2 80 83  e2 80 83 e2 80 83 e2 80  | ... ...........|

何かしら書かれているということで、hexdumpしてみた。e2 80 83が繰り返されているのかと思ったが、時々20が入っている。ASCII変換されたものを見るとスペースになっているようだ。もしかして、スペースを用いて何かしら書いているのだろうか？わからぬ。 (picoCTF 2019 WhitePages - Points: 250)を見た。(EM space)といわれるスペースがあるようだ。つまり、e2 80 83と20の二つ＝二進数で書かれているという感じらしい。

od whitepages.txt -An -tx1 -v|tr '\n' ' '|tr -d ' '|sed -e "s/e28083/0/g"|sed -e "s/20/1/g"

(【Shellスクリプト】文字列置換「bash」「sed」について！) (trコマンドで空白文字を削除) (od コマンド) ここを用いて、コードは作った。これで二進数にできた。cyberchefでbinaryにするとflagでた。

Eavesdrop

Download this packet capture and find the flag.ということで、pcapファイルを受け取った。
今までは通信のやり取りの理解を先にやっていたが、解析から迫っていきたいと思う。(CTFのフォレンジックにおけるネットワークフォレンジックまとめ [Wireshark, pcap])を参考にする。

プロトコル階層を眺めるとよいとのこと。UDPやTCPでのやり取りを行っている。TCPではHTTPやDataのやり取りがされている。エンドポイントはこんな感じ。パケット数が少ない方に注目した方が良いのか？
また、問題文のeavesdropは盗聴という意味。ではパケットは少ない方に注目かな。
　　少ないやり取りをしている10.0.2.1と10.0.2.3に注目した。DNS名前解決している問い合わせかな？DHCPってなんや？

知識(DHCP)

DHCP

(DHCPとは)。つまり、IPアドレスをもらうための通信ということだと思う。 (DHCP reuestについて)

さて、つまり、初めは10.0.2.15が10.0.2.3(DHCPサーバ)に通信をしている感じ。10.0.2.15が主役っぽい。10.0.2.1はDNS名前解決していると考える。

次に、少ない35.224.170.84についてみてみる。HTTP通信を確立させようとしている。実際成功しているが中身がなかったようだ(204 no content)。なので終了している。hint何かヒントになるのだろうか？
それでは全体を見る。10.0.2.15と10.0.2.4がやり取りを行っているように見える。ARP通信が気になるがipaアドレスとmacアドレスを紐づけるプロトコルのようだ。あんまり不信感はない。
盗聴なので10.0.2.15と10.0.2.4のやり取りを見ていく。そうするとflagの復号どうやってやるのという会話をしている。
openssl des3 -d -salt -in file.des3 -out file.txt -k supersecretpassword123しかも答えてる。その後にflagも送ってくれと言っている。Oh great. Ok, over 9002?ということで、port：9002でやり取りするようだ。
その後、Saltedから始まるものをやり取りしている。これ前の問題で見たことあるで。Operation Orchidでやった問題です。Saltedから始まるASCIIをflag.des3ろいうファイルにコピーして復号コマンドをたたいた。可読文字にならない。なぜでしょう。
(writeup)こちらを参考にした。その通りにやったらできた。

知識(TCP通信盗聴対策)

TCP通信盗聴対策

あと、TCP通信でのやり取りは盗聴されてしまうならどうすればよいのだろうか。(実践で学ぶ、一歩進んだサーバ構築・運用術) 対策としては「SSL/TLSなどの技術を使用して、TCPの通信内容を暗号化することが一般的です。」だそうです。 (TCPとは？わかりやすく10分で解説)

考察

考え方はあっていた(writeupの方が数段スマートでした。)ただ、コピペなどを用いると少しずつ違ってくるのだと思う。できる限り、プログラム上でやり取りできるように考えていくことが大切だと感じた。

[2024/02/27]

WPA-ing Out

I thought that my password was super-secret, but it turns out that passwords passed over the AIR can be CRACKED, especially if I used the same wireless network password as one in the rockyou.txt credential dump. Use this 'pcap file' and the rockyou wordlist. The flag should be entered in the picoCTF{XXXXXX} format.

まず、rockyou.txtとは何かを調べた。

知識(rockyou.txt)

rockyou.txt

(RockYou.txt とは：セキュリティのためのツールかつハッカーにとっての武器)を参考にした。今までに存在するパスワードの辞書のようだ。

(brannondorsey)から入手した。

次にpcapファイルを確認していく。wireless LANで通信を行っている。少しはDATAをやり取りしている。
初手が分からないので、(CTFのフォレンジックにおけるネットワークフォレンジックまとめ [Wireshark, pcap])を参考にしていく。

無線(W)→無線LAN トラフィックから無線LAN統計が確認できた。
列の属性を少し見ていく。

知識(無線LAN)

BSSID

(Wireless LAN - BSSID & ESSID)を参考にした。つまり、無線通信時のエンドポイントIDという感じだろうか。

ちなみに、(Download: Wireshark Coloring Rules File)を参考に無線通信にも色付けしている。わからなさ過ぎたのでヒント2を見た。「Aircrack-ng can make a pcap file catch big air...and crack a password.」らしい。 (ハッカーはaircrack-ngで無線LANの解析を確認する(Kali Linux))を参考に使い方を学んだ。└─# aircrack-ng wpa-ing_out.pcap -w rockyou.txtを実行すると rockyou.txtの中からパスワードをクラックすることができるようだ。そうすると早々に見つかる。そのワードをpicoCTF{}の中に入れれば終了。

FindAndOpen

Someone might have hidden the password in the trace file. Find the key to unlock this file. This tracefile might be good to analyze. ということで、zipファイルとpcapファイルを渡された。zipは解凍するのにpasswordが必要なようだ。そのパスをpcapから探すというものらしい。
階層

知識(Ethernet)

Ethernet

イーサーネットは主に有線LANでの通信規格のことらしい。(今さら聞けない「イーサネット」。次世代自動車もつなぐネットワーク技術とは)。また、IPv4とIPv6の違いがあるようだ(IPv4とIPv6の違いは速度だけ? 知っておくべき比較ポイント)。セキュリティ的にはIPv4の方が暗号化がオプションのようだ。今回はDATAがIPv4の方にしかないのでそこまで問題ではなさそう。

今回パケットが少なかったので、DATAを見てると48パケットに末尾が=のものがあった。つまり、Base64で暗号化されているものが流れているようだ。それをcyberchefでデコードすると、This is the secret: picoCTF{R34DING_LOKd_と別れたflagが見つかった。Could the flag have been splitted?というパケットが流れているので分けられているようだ。Maybe try checking the other fileとそのあとに通信しているので、zipファイルに残りがあると考えらえれる。
どう考えても見当たらない。Writeup確認してみる。(WriteUp)。抽出した部分的なflagがパスになっているらしい。なんじゃそりゃ。一応終了。

[2024/02/28]

shark on wire 2

We found this packet capture. Recover the flag that was pilfered from the network.
(CTFのフォレンジックにおけるネットワークフォレンジックまとめ [Wireshark, pcap])を参考にする。Follow TCP Streamを見たがめぼしい情報はない。

IPv4のUDPパケットが多いと読み取れる。Address Resolution Protocolがその次に多い。
思った以上に通信しているエンドポイントが多い。パケット量が多いのは10.0.0.1である。これが自分の端末かな？その次に多い192.168.2.1がもしかしたら何かしらなのかもしれない。怪しいと思うことをいかにまとめた。

UDPの通信内容にpicoCTFのような言葉が使われているようだ。
1104に文字列start、1303に文字列endがある。なにかあるのかな？
sourceに10.0.0.1の時に一文字ずつ送られている？ *source 10.0.0.2, destination10.0.0.13のUDPストリームがkfdsalkfsalkico{N0t_a_fLag}となっている。
source10.0.0.2, destination10.0.0.12のUDPストリームがicoCTF{StaT31355eとなっていて怪しい。
10.0.0.8が10.0.0.29にI really want to find some picoCTF flagsと送っている。29が知っているのか？→そんなことはない。

ここまでやってお手上げ、WriteUpを見る。(writeup)を参考にした。portが鍵のようだ。確かに、startからendの間のパケットでport srcの数はやたらに多い気がする。

参考のとおり、udp and ip.dst == 10.0.0.1 and ip.addr == 10.0.0.66でフィルターした後の、Src portの下三桁を抜き取り、ASCIIで表示したらflagゲット。

WebNet0

We found this packet capture and key. Recover the flag.
ということで、pcapファイルと.keyファイルを渡された。.keyファイルの内容は以下のとおりである。

└─# cat picopico.key
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCwKlFPNKjseJF5
puCJU5x38XcT1eQge5zOKNahAlYudvGVOEs61TnIgvcER4ko8i3OCwak2/atcGk3
oz9jFKep7XFEYNP31IwwD9j/YazlKy4DRLGObOyIZUU1f2WRA7Uhf0POQXsDT1oU
X32jMKZkQSSDW4MRZd9trJYdO2TrcEPMsBiZQlFlvgnNwl3QlawozTHLAJKI36j1
cPwSMMeNca1e0Zi1s7R5IxfhpNXOBF0FmxiWvmeOHbaspyHg8UEmGBrkd4k4wXSK
GQvrc8QjycP4ScEdquxJiYnDT8iEbAq70/7f/5NIN1DE9YoGJqKYjTS9nRPB4Yvj
JN/SJnhvAgMBAAECggEACCnd3LrG/TZVH3sROqvqO1CwQPYPfUXdLVyNHab7EWon
pc+XBOHurJENG2CpRYF7h+nQ5ADhfIYSCicBf/jsEB7VueJ20CxEVtHVL3h6R6Bp
oHMle0Em8OcofuMpdL/kO+om3T8BkVSzCvCl5NMTUuAF7iRmfX7oDLALwM0IzzQv
2un+2UmT15rgAZfl3IL1PGvJhbhLxfeeyPE9MBy1SqBjQ9rNFn8sQv959J6BHz4b
EpK//ErtNP2yh7oiVBBgKEQ1gEuOjQC/4oxoqCFfZaf9XNRCxB/zY1nUprvJyz09
NMQWNF2EmvmBVGfoTxmuut5N0GbVr2UyHxWMKm2sOQKBgQDpb2+AWgWlGtetuLKJ
fJs8dnd6LhnafbKCOXMOT68qMBRoTpBtVTLRVSNvWCm8m4TTEazX4+ZA+bJFwUFw
aATDmHcr6lMI3tNKrcsnY2F7o5I4z6mwuRuSeszq/ndxZqCzwCu4nKixh3cznp7j
JiElNG0d8Lu5eQgmVAK1AhWXfQKBgQDBMa9ga7VJUP4pzcHnWAoi34OpfjvQYeGl
IKL3AKO4OedaHdH9qid41PQHnL7O3xzN669SkLZ5s0d88A/LFLk4oZNMKdkSTQIQ
+AMbXH01HGFvnCOuPg/FbNp1wS7zJEg5u5HFQWyMPNJLr/hZ6g2Yp+UGpAcGTwM/
RCPVAPhLWwKBgQDAB0OaOnPaVjKGXiHAqBirrGiswa/S5QQrzEaxxys5cUPYaoi0
6BldysPTnJr45JZna2rcTkXjvYTBjTDf3zHMFWgzYBfefC8kh8NPK5nNs8ldorbd
AemEnjBkP+DSELKyK6vLulOrdtzAQgRCp+MsT+xTbO2ArefeX826SXSpoQKBgC2v
nDOHBQXje1dTawlUToFUrgQE8AwlOYEdKKyUoCLOvqEW8DO2a0MtyM+MB6tQI7Wm
iH1T73L0LHGlK3bw3aRAwV5/fu/O+jAdFk8AHjPTFE+acu2fi4c6aKb0GjAxYksU
yjIFeK/pKinv4SESMkjpW0WowGiDgtcRPBAA/LaFAoGAfEM1rfM0v3UmB7PS6u0m
P3ckP2CFCdaryXPfC52GBcJ3Q46YpsQvLTVotM+teHvTjNw2jwwZxIl4NenGSEj3
KDhQoOiQC9BrDD+DB4I9+T9nxT3g7R6MrgITghB4We7TVhL/PljnJTyDqpjNA4kY
TveAJPv6Xq1ERt5PUtX3BqQ=
-----END PRIVATE KEY-----

秘密鍵のようだ。

パケットはTCPが行われているようだ。

エンドポイントはこんな感じ。二人の間で秘密通信が行われているといった感じかな？
プロトコルを見ているとTLSv1.2があるなんだろう？

知識(TLSv1.2)

TLSv1.2

(SSL/TLSの仕組み)を参考にした。前述べたと思うけど、TCP通信は暗号化されないので危険であるということで、暗号化を行って通信を安全にする仕組みがTLSだそうだ。v1.2はそれ以前に見つかった脆弱性を修正したバージョンと思う。

ここで、TLSの復号について調べるとwiresharkにそういう機能があるようだ。(【Wireshark】WiresharkでSSL/TSLの暗号化通信を復号化する)を参考にした。ここのところでは編集→設定(P)→protocolsの中からTLS選択→RSA keys listの編集→key FIleのパスを選択しOKするとHTTPの中身が見えるようになる。

中身を見ていくと、Pico-Flagという属性にflag形式あり。flagゲット。

Operation Oni

Download this disk image, find the key and log into the remote machine. Note: if you are using the webshell, download and extract the disk image into /tmp not your home directory. Download disk image Remote machine: ssh -i key_file -p 62260 ctf-player@saturn.picoctf.net ということで、イメージディスクを調査するようだ。楽しみ。

└─# ssh -i key_file -p 62260 ctf-player@saturn.picoctf.net
Warning: Identity file key_file not accessible: No such file or directory.
The authenticity of host '[saturn.picoctf.net]:62260 ([13.59.203.175]:62260)' can't be established.
ED25519 key fingerprint is SHA256:XBSvB1lk28EctsAVdKJtsl0A7C5bonqPrvHCYH8aEy4.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes
Warning: Permanently added '[saturn.picoctf.net]:62260' (ED25519) to the list of known hosts.
ctf-player@saturn.picoctf.net's password:
Permission denied, please try again.
ctf-player@saturn.picoctf.net's password:
Permission denied, please try again.
ctf-player@saturn.picoctf.net's password:
ctf-player@saturn.picoctf.net: Permission denied (publickey,password).

sshするとパスワードを求められるので、そのパスを求めるのが課題のようだ。
まず初手、

└─# file disk.img
disk.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0xc,223,19), startsector 2048, 204800 sectors; partition 2 : ID=0x83, start-CHS (0xc,223,20), end-CHS (0x1d,81,52), startsector 206848, 264192 sectors

2つのセクターに分かれているようだ。

└─# mmls disk.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000206847   0000204800   Linux (0x83)
003:  000:001   0000206848   0000471039   0000264192   Linux (0x83)

やはり二つに分かれている。オフセットも把握。

└─# fls disk.img  -o 2048
d/d 11: lost+found
r/r 12: ldlinux.sys
r/r 13: ldlinux.c32
r/r 15: config-virt
r/r 16: vmlinuz-virt
r/r 17: initramfs-virt
l/l 18: boot
r/r 20: libutil.c32
r/r 19: extlinux.conf
r/r 21: libcom32.c32
r/r 22: mboot.c32
r/r 23: menu.c32
r/r 14: System.map-virt
r/r 24: vesamenu.c32
V/V 25585:      $OrphanFiles

└─# fls disk.img  -o 206848
d/d 458:        home
d/d 11: lost+found
d/d 12: boot
d/d 13: etc
d/d 79: proc
d/d 80: dev
d/d 81: tmp
d/d 82: lib
d/d 85: var
d/d 94: usr
d/d 104:        bin
d/d 118:        sbin
d/d 464:        media
d/d 468:        mnt
d/d 469:        opt
d/d 470:        root
d/d 471:        run
d/d 473:        srv
d/d 474:        sys
V/V 33049:      $OrphanFiles

この感じだと2つ目に情報がありそう。homeとルート見に行こう。 homeに情報はなさそう。rootには.ssh ディレクトリがあり、公開鍵と秘密鍵があった。sshがパスワードではなく、鍵認証だとすると難しい。

└─# icat disk.img 2345 -o 206848
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACBgrXe4bKNhOzkCLWOmk4zDMimW9RVZngX51Y8h3BmKLAAAAJgxpYKDMaWC
gwAAAAtzc2gtZWQyNTUxOQAAACBgrXe4bKNhOzkCLWOmk4zDMimW9RVZngX51Y8h3BmKLA
AAAECItu0F8DIjWxTp+KeMDvX1lQwYtUvP2SfSVOfMOChxYGCtd7hso2E7OQItY6aTjMMy
KZb1FVmeBfnVjyHcGYosAAAADnJvb3RAbG9jYWxob3N0AQIDBAUGBw==
-----END OPENSSH PRIVATE KEY-----

└─# icat disk.img 2346 -o 206848
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGCtd7hso2E7OQItY6aTjMMyKZb1FVmeBfnVjyHcGYos root@localhost

ちなみに

└─# fsstat -t disk.img -o 206848
ext4

ここからはautopsyを使用して調査しようと思う。(CTFのフォレンジックにおけるディスクイメージフォレンジックまとめ [ファイルシステム])を参考に見る。rootディレクトリにある.ash_historyを確認。

ssh-keygen -t ed25519
ls .ssh/
halt

鍵を生成しているようだ。次に/var/logを確認。

messagesがlocalhostが行ったことを表しているのだろうか？(/var/log以下のログ一覧)を参考に載っているファイルがなんのログを表しているのかおおよそつかむ。

chrony :ちょっとよくわかんない。でも、中身がないのでいったん飛ばし。
acpid.log :(マコトのおもちゃ箱　～ぼへぼへ自営業者の技術メモ～)電源周りのログのようだ。
dmesg :システム起動からファイルシステムマウントまでのカーネルログ
messages :syslogを使用したログ *wtmp :login success一覧

wtmpがログイン系なので怪しい。(/var/log/wtmp の内容を確認する)を見るとパスワードはなさそうな予感。ここで、純粋にパスワードを確認できないか調べる。/etc/shadowにあるようだが、rootしかない。しかも、暗号化されているし。今回のユーザーではなさそう。そうなるとパスワード認証自体が怪しい。最初のログインに失敗した画面を見る。ctf-player@saturn.picoctf.net: Permission denied (publickey,password).公開鍵とパスワードの認証拒否なので、公開鍵を使えるのかな？(sshのPermission deniedを解決する方法)鍵が必要な感じになってきました。ssh -i key_file -p 54955 ctf-player@saturn.picoctf.net sshするコマンドを見ると-iオプションがあることに気づく。(【 ssh 】コマンド――リモートマシンにログインしてコマンドを実行する)を見るとやはり、秘密鍵のファイルを指定している。つまり、ログインするユーザーの秘密鍵をsshするときのディレクトリにkey_fileの名前で配置するのが正解かな？/etc/sshにある秘密鍵と/roo/.sshにある秘密鍵を抽出してこのファイルを指定してログインを試す。

└─# ssh -i id_ed25519 -p 55245 ctf-player@saturn.picoctf.net
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_ed25519": bad permissions
ctf-player@saturn.picoctf.net's password:

とエラーが出た。他の人が触れないことが必要ということだろうか？(SSH接続しようとしたら秘密鍵のパーミッションエラーがでた)を参考にした。権限を変えてアクセスしたら成功。lsしたらflagファイルがあるのでcatしておしまい。

WebNet1

We found this packet capture and key. Recover the flag.というわけでpcapファイルと.keyファイルを渡されている。

└─# cat picopico.key
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCwKlFPNKjseJF5
puCJU5x38XcT1eQge5zOKNahAlYudvGVOEs61TnIgvcER4ko8i3OCwak2/atcGk3
oz9jFKep7XFEYNP31IwwD9j/YazlKy4DRLGObOyIZUU1f2WRA7Uhf0POQXsDT1oU
X32jMKZkQSSDW4MRZd9trJYdO2TrcEPMsBiZQlFlvgnNwl3QlawozTHLAJKI36j1
cPwSMMeNca1e0Zi1s7R5IxfhpNXOBF0FmxiWvmeOHbaspyHg8UEmGBrkd4k4wXSK
GQvrc8QjycP4ScEdquxJiYnDT8iEbAq70/7f/5NIN1DE9YoGJqKYjTS9nRPB4Yvj
JN/SJnhvAgMBAAECggEACCnd3LrG/TZVH3sROqvqO1CwQPYPfUXdLVyNHab7EWon
pc+XBOHurJENG2CpRYF7h+nQ5ADhfIYSCicBf/jsEB7VueJ20CxEVtHVL3h6R6Bp
oHMle0Em8OcofuMpdL/kO+om3T8BkVSzCvCl5NMTUuAF7iRmfX7oDLALwM0IzzQv
2un+2UmT15rgAZfl3IL1PGvJhbhLxfeeyPE9MBy1SqBjQ9rNFn8sQv959J6BHz4b
EpK//ErtNP2yh7oiVBBgKEQ1gEuOjQC/4oxoqCFfZaf9XNRCxB/zY1nUprvJyz09
NMQWNF2EmvmBVGfoTxmuut5N0GbVr2UyHxWMKm2sOQKBgQDpb2+AWgWlGtetuLKJ
fJs8dnd6LhnafbKCOXMOT68qMBRoTpBtVTLRVSNvWCm8m4TTEazX4+ZA+bJFwUFw
aATDmHcr6lMI3tNKrcsnY2F7o5I4z6mwuRuSeszq/ndxZqCzwCu4nKixh3cznp7j
JiElNG0d8Lu5eQgmVAK1AhWXfQKBgQDBMa9ga7VJUP4pzcHnWAoi34OpfjvQYeGl
IKL3AKO4OedaHdH9qid41PQHnL7O3xzN669SkLZ5s0d88A/LFLk4oZNMKdkSTQIQ
+AMbXH01HGFvnCOuPg/FbNp1wS7zJEg5u5HFQWyMPNJLr/hZ6g2Yp+UGpAcGTwM/
RCPVAPhLWwKBgQDAB0OaOnPaVjKGXiHAqBirrGiswa/S5QQrzEaxxys5cUPYaoi0
6BldysPTnJr45JZna2rcTkXjvYTBjTDf3zHMFWgzYBfefC8kh8NPK5nNs8ldorbd
AemEnjBkP+DSELKyK6vLulOrdtzAQgRCp+MsT+xTbO2ArefeX826SXSpoQKBgC2v
nDOHBQXje1dTawlUToFUrgQE8AwlOYEdKKyUoCLOvqEW8DO2a0MtyM+MB6tQI7Wm
iH1T73L0LHGlK3bw3aRAwV5/fu/O+jAdFk8AHjPTFE+acu2fi4c6aKb0GjAxYksU
yjIFeK/pKinv4SESMkjpW0WowGiDgtcRPBAA/LaFAoGAfEM1rfM0v3UmB7PS6u0m
P3ckP2CFCdaryXPfC52GBcJ3Q46YpsQvLTVotM+teHvTjNw2jwwZxIl4NenGSEj3
KDhQoOiQC9BrDD+DB4I9+T9nxT3g7R6MrgITghB4We7TVhL/PljnJTyDqpjNA4kY
TveAJPv6Xq1ERt5PUtX3BqQ=
-----END PRIVATE KEY-----

keyは秘密鍵のようだ。

階層はIPv4でTCPとTLSが行われているようだ。

ポートが違うが2人の人が通信を行っているようだ。 WebNet0と同様に秘密鍵を登録しようと思う。WebNet0と同様にいくつかの暗号化されていたものが復号された。42パケットに書かれているhtmlに画像を渡すようにことが書かれている。

<title>Hello, world!</title>
  </head>
  <body>
    <div class="container">
            <div class="starter-template">
                <h1>Welcome to A Secret Page</h1>
                <p class="lead">
                Here is a picture for you!
            </p>
            <img src="vulture.jpg" alt="my pantaloons" /> 
            </div>
    </div><!-- /.container -->

HTTPオブジェクトをエクスポートする。
やはり気になるのはvulture.jpgである。ファイルを渡されたら初手はfileとstringsコマンドである。

└─# file vulture.jpg
vulture.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=5, xresolution=74, yresolution=82, resolutionunit=1], baseline, precision 8, 640x716, components 3

ダメもとで└─# strings vulture.jpg | grep picoと打ったらflag出てきた、入力したら通った。終了。

[2024/02/29]

Torrent Analyze

SOS, someone is torrenting on our network. One of your colleagues has been using torrent to download some files on the company’s network. Can you identify the file(s) that were downloaded? The file name will be the flag, like picoCTF{filename}. Captured traffic.
まずはtorrentを知らないので調べる。

知識(Torrent)

Torrent

(Torrentとは? 使い方/ダウンロード方法/逮捕される?/違法/危険性/用語【完全ガイド】)を参考にした。P2P技術を利用して、ファイルをダウンロード、アップロードできる仕組みのようだ。

Torrentでダウンロードされたファイルの名前を特定する問題のようだ。

IPv4でUDPとTCPが行われているようだ。UDPのほとんどでDATAがやり取りされている。エンドポイントを確認すると156のアドレスがやり取りしている。何とも特定しにくい。

しかし、パケットの数でソートすると192.168.73.132が多くのパケットを受信していることが分かる。Torrentでは多くのユーザーから一つのファイルの断片を受信して完成させるので、受信パケットが多いのは鍵になりそう。
まずは文字列でtorrnetを検索する。そうするとBitTorrent DHT Protocolといういかにもというプロトコル発見。

知識(BitTorrent DHT Protocol)

BitTorrent DHT Protocol

(BitTorrent の分散ハッシュテーブル（DHT）やマグネットリンクとは)を参考にした。(P2P通信技術: BitTorrentプロトコルを用いた大容量データ配信)はダウンロード方法がわかりやすい。(torrent(トレント)ファイルとは？)トレントファイルについてはこちらを見た。

他にも気になることを書いていく。

BT-DHTではrequestとresponseというものがありそう。
また、request typeというものがありそう。pingやget_peersとあり

知識(wireGuard)

wireGuard

(オープンソースVPN 「WireGuard」とは？ホワイトペーパーから読み解く仕組みや実用性)を参考にする。

hintを見た。「Try to understand peers, leechers and seeds.」とあった。

知識(peers, leechers and seeds)

peers, leechers and seeds

(P2Pwiki)を参考にした。peerはネットワーク上に存在する端末。leechersは完全なファイルを持っていない、つまり、ダウンロード中の端末。seedsは完全なファイルを持っている端末である。

上記の知識を読み直して考えたこととしては、まずダウンロードするためにはどこかにあるtorrentファイルを管理しているサーバーにアクセスしてファイルを取得し、トラッカーにアクセスしたのちにピア間での通信が始まると考えられる。ので、ファイル名を探すなら、管理しているサーバーかトラッカーへの通信にファイル名がありそうと考えられる。初めに思ったのは最初にTLS通信を行った切後半あまり出てこない91.189.95.21が管理サーバーなのかと思って調べたが、TLS通信をしているせいで中身が見れないこと。何かしらの受け渡しがあったのはわかるが中身が見れないので、駄目っぽい。パケットを眺めているとやはりrequest typeが気になる。調べた。(Sniffing BitTorrent DHT ～人はBTで何を落とすのか～)に書いてある。つまり、get_peerタイプのinfo_hashに欲しがっているファイル情報があるようだ。そして、そのハッシュはSHA-1で行われているようだ。get_peerクエリはたくさんあるが同じハッシュ値を聞いていることもある。

17d62de1495d4404f6fb385bdfd7ead5c897ea22(パケット79)
d59b1ce3bf41f1d282c1923544629062948afadd(パケット429)
078e18df4efe53eb39d3425e91d1e9f4777d85ac(パケット436)
7af6be54c2ed4dcb8d17bf599516b97bb66c0bfd(パケット1587)
17c0c2c3b7825ba4fbe2f8c8055e000421def12c(パケット3999)
17c02f9957ea8604bc5a04ad3b56766a092b5556(パケット36047)
e2467cbf021192c241367b892230dc1e05c0580e(パケット51080,51081,51082,51179,51212,51464,51519,51679...)

これでハッシュを逆引きできればよかったが、逆変換するツールが見当たらない。このハッシュに対応するファイルがあるのだろうか？それってTLSで通信されていたとか？あと一歩のとこまで来ているようなのに、わからん。
WriteUp見てしまった。(picoCTF2022 Torrent Analyze を勉強した記録)導きかだがスマート。あと一歩だった。スマートに解こうとしてしまったが、検索すればよかったのか。検索して一応flagゲット。

考察

今回の問題の最後でhash値を渡された。ツールなどを考えたが、その前に検索というものを考えた方がよかったようだ。他のCTFでも検索でhash値を解読したことを思い出した。しかし、今回のやつググってもCTF関係のものしか出てこないので、なかなかwriteupなしにたどり着くのは難しかったと思う。
また、今回のハッシュ値はリストの一番下のものだった。そのほかは違うようだ。最後のパケットだけ192.168.73.132がリクエストを飛ばしている。これがユーザーがダウンロードしようとしていることらしい。そのほかはリクエストされる方だったので、ファイルをアップロードする側だったということかな？
今回あと一歩だったが、なかなか奮闘したと思う。これからも頑張るのみ。

[2024/03/06]

scrambled-bytes

I sent my secret flag over the wires, but the bytes got all mixed up!ということで、 pcapファイルとpyファイルを渡された。pyファイルを実行してメッセージを送ったようだ。
まずは、コードを解読していきたいと思う。

#!/usr/bin/env python3

import argparse
from progress.bar import IncrementalBar

from scapy.all import *
import ipaddress

import random
from time import time

if __name__=='__main__':
  parser = argparse.ArgumentParser()
  parser.add_argument('destination', help='destination IP address', type=check_ip)
  parser.add_argument('port', help='destination port number', type=check_port)
  parser.add_argument('input', help='input file')
  main(parser.parse_args())

コードの書き順を変えた、実行される順に見ていこうと思う。
argparse.ArgumentParser()は(ArgumentParserの使い方を簡単にまとめた)を見てみると、pythonによる引数を取得できる仕組みのようだ。parser.add_argumentで引数を追加。そして、parser.parse_args()で引数を解析するようだ。コード内で使われる変数の意味は下のようになる。

destination : destination IP address (type=check_ip)
port : destination port number (type=check_port)
input : input file

また、typeにより、記述されている関数を行った後の結果を扱うこともできる。つまり、destinationはcheck_ipを実行した後のreturn値である。そして、解析されたdestination、port、inputをmainに渡してコードが実行されるようだ。

def check_ip(ip):
  try:
    return ipaddress.ip_address(ip)
  except:
    raise argparse.ArgumentTypeError(f'{ip} is an invalid address')

def check_port(port):
  try:
    port = int(port)
    if port < 1 or port > 65535:
      raise ValueError
    return port
  except:
    raise argparse.ArgumentTypeError(f'{port} is an invalid port')

そして、destinationとportが引数に渡される前に実行される関数を見ていく。ipaddress.ip_address(ip)はpythonでIPアドレスを扱う関数のようだ(pythonでIPアドレスを扱う方法)。渡された値がIPアドレスなのかをチェックするようだ。そして、portはint型にしたのちに1以上65535以下であるかをチェックしている。

知識(ポート)

ポート

(TCP/UDPにおけるポート番号について)を参考にした。ポートは65535までしかないようだ。そして、それで、プログラムへの通信を設定できるようだ。

def main(args):
  with open(args.input, 'rb') as f:
    payload = bytearray(f.read())
  random.seed(int(time()))
  random.shuffle(payload)
  with IncrementalBar('Sending', max=len(payload)) as bar:
    for b in payload:
      send(
        IP(dst=str(args.destination)) /
        UDP(sport=random.randrange(65536), dport=args.port) /
        Raw(load=bytes([b^random.randrange(256)])),
      verbose=False)
      bar.next()

さて、本丸です。ここで、送りたいものをいじっているようだ。
まず、inputファイルを開けている。それがpayloadとして扱われていくようだ(ペイロードとは)。
その次にtimeをシードにrandom.shuffleでbyte列をぐちゃぐちゃにされたようだ。
IncrementalBarは進捗の進み具合を可視化してくれるようだ(プログレス1.6)。送信している大本はその次のfor文である。send関数はscapyライブラリで定められているようだ(Scapy入門)。パケット通信を行うことを可能にしているらしい。パケットは/で区切られている。
IPではあて先アドレスを指定。
UDPではsportで送信元ポートを指定している。今回は65536の間の数値をランダムで割り当てている。dportはあて先ポートである。(Scapyって知ってる？)こっちのサイトの方が分かりやすいかも。Rawはpayloadを表しているようだ。また、b^random.randrange(256)は受け取ったpayloadをrandom.randrange(256)で割り当てられた乱数と排他的論理和をとって送信されているようだ(とほほのPython入門 - 演算子)。肌間ではflagを見つけるというより解読する問題のように感じる。

では、pcapファイルを見ていく。
プロトコル階層。IPv4でのTCPが多いようだ。しかし、payloadの送信はUDPだったような。Internet Control Mssage Protocolも少しあるようだ。あまり有益な情報はないかも。

知識(ICMP)

ICMP

(ICMPとは？TCP/IPの通信状態を確認するプロトコル)を参考にした。通信の意思疎通ができているかを確認するプロトコルのようです。

エンドポイントについて。ちなみにUDPを確認すると172.17.0.2が大量のポートを利用していたので上記のコードを実行してパケットを送っているのは172.17.0.2だと考えられる。UDPの送信先が172.17.0.3であるので、この2者とのやり取りが肝のように思う。
しかし、pyコードを見ているが、random.shuffleやワンタイプパッドのように送信ペイロードに乱数を排他的論理和して暗号化しているので、復号するのは難しいと考えられる。可能だと考えられるのはrandom.seedを特定することだと考えられる。random.seedはint(time())で表されている。timeで出力されるのはタイムスタンプというものらしい。

知識(タイムスタンプ)

タイムスタンプ

(Pythonのtimeモジュールまとめ！処理時間を計測する方法)を参考にした。「これはタイムスタンプという時刻の表示形式で、 1970年1月1日0時0分0秒から何秒経っているかを教えてくれます。」だそうです。

wiresharkでは通信された時間が分かる。タイムスタンプも記述されている。ここから、random.seedを求めることはできないかと考えた。wiresharkのepoch timeというところで確認できる。UDP通信が始まったのが1614044650.913789387となっているのでint型にすると1614044650となる。この前後がrandom.seedになっているのではないかと予想している。
しかし、ここの手法のおかしいかもと思うのはUDPパケットは1992ものパケットが送信されている。flag以外の文字を含んでいるとしても長い。もっとスマートな解き方があるのだろうか？あと気になるのが、ICMPのエラーである(【初心者わかりやすく】ICMPを詳しく解説)。等間隔に行われているように見えてしまう。でもきっちり等間隔ではなさそう。この時のpayloadだけ受け取れていないのだろうか？
また、ここで気になったのは同じのportで送信しているときがないかである。ランダムなので重なるときはあるかもしれないが、一応気になるので検索。

少なからずある。なにかしらの規則性があるか見たが、共通して規則性があるとは言えなかった。
(picoMini by redpwn writeup)を見てしまった。この発想を持つのむずすぎませんか？
tsharkの方がパイプやリダイレクトできるので、ほかのコマンドと組み合わせられるのは大きな利点のように思う。なので、wiresharkで抽出したいなどの細かい作業はtsharkで行うと思うとよい。しかし、抽出のコマンドが難しいのが注意点。どこかにまとめサイトあればよいが、見当たらない。今回、udpのdataをtsharkで集めた。思いのほか簡単に集まった。(よく使うtsharkワンライナーのメモ)を参考に行った。tshark -r capture.pcapng -Y "udp and data.len == 1 and ip.src != 172.17.0.3" -T fields -e data |tr '\n' ' ' > output.txtで抽出はできたと思う。やってみたがうまくいかない。(0x534b/ctf-writeups )を参考にするとエラーはいてたところにも少し手を加えないといけないようだ。
さて、手を加えていく。まずはwireshark上でフィルタしていく。udp and !icmp and ip.src == 172.17.0.2 and ip.dst == 172.17.0.3。そうするとUDP以外の3つのエラーパケットが見つかった。ここをちゃんとする。というかこれは抽出できていないのだろうか。やってみたが無理っぽい。やっぱり手動だろうか。
複雑な処理をしてでもプログラムで抽出したいと思い、(Scapyでpcapファイルからデータを抽出する)を参考にプログラムを書いてみることにした。

from scapy.all import *
p = rdpcap('./capture.pcapng')
p[1942].show()

というコードではエラー処理されていたもののpayloadも抽出できた。でかい。

from scapy.all import *
p = rdpcap('./capture.pcapng')

for i in range(10936):#
    if('IP' in p[i]):
        if (p[i][IP].src == "172.17.0.2"):
            try:
                print(p[i][Raw].load)
            except Exception as e:
                print(b'\x69')

試行錯誤したらこれで抽出できた。なぜかエラー処理が起きたが、対応できた。ascii変換されてしまっているのは少し面倒かも。printせずに内部で処理したらできると思うので、このままプログラムで進めていく。
改良の末、実行できた。

from scapy.all import *
import random
import binascii

#暗号化データ抽出
p = rdpcap('./capture.pcapng')
enc_data = []
for i in range(10936):
    if('IP' in p[i]):
        if (p[i][IP].src == "172.17.0.2"):
            try:
                enc_data.append(p[i][Raw].load)
            except Exception as e:
                enc_data.append(b'\x69')
enc_data = b''.join(enc_data)

shuffle = []
for i in range(len(enc_data)):
        shuffle.append(i)

random.seed(1614044650)
random.shuffle(shuffle)

dec_data = [b"\x00"]*len(enc_data)

k = 0
for b in enc_data:
        random.randrange(65536)
        dec = bytes([b^random.randrange(256)])

        dec_data[shuffle[k]] = dec
        k = k +1

print(b"".join(dec_data))
with open("solved.png", 'wb') as f:
      f.write(b"".join(dec_data))

これで出力されたデータのヘッダーがb'\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x01\xaa\x00\x00\となっており、PNGデータであることが把握できる。そこで画像を確認すると、flagあり。終了。

できなかった要因。

payloadを全部まとめて一つのファイルに集めることができることを知らなかった。ストリーム以外にもtsharkを用いるとできるようだ。これができていれば一つハードルは下がっていたように思うが、その発想ができなかった。
そしたら、どうにか実行してできたような気がする。負け惜しみです。次はもう少し粘ってみようと思いました。また、tsharkというより、プログラムで扱うことができたようだ。pwnでもそうだがプログラムでなせることが多いので、手が止まったらそのようなプログラムはできないかを考えてみてもよいかも。

Scan Surprise

I've gotten bored of handing out flags as text. Wouldn't it be cool if they were an image instead?
ということで画像が渡される。それがqrコードなのでそれを読み込むとよいそうだ。(QRコード解析)を使うとできた。

Verify

People keep trying to trick my players with imitation flags. I want to make sure they get the real thing! I'm going to provide the SHA-256 hash and a decrypt script to help you know that my flags are legitimate. You can download the challenge files here: challenge.zip The same files are accessible via SSH here: ssh -p 55515 ctf-player@rhea.picoctf.net Using the password f3b61b38. Accept the fingerprint with yes, and ls once connected to begin. Remember, in a shell, passwords are hidden! Checksum: fba9f49bf22aa7188a155768ab0dfdc1f9b86c47976cd0f7c9003af2e20598f7 To decrypt the file once you've verified the hash, run ./decrypt.sh files/.

つまり、与えられているファイルのsha256で正解のファイルを当てるという問題。(SHA256ハッシュ値を確認する)から、linuxでのsha256の確認方法が分かった。ctf-player@pico-chall$ sha256sum ./files/*とするとフォルダ内にあるファイルのハッシュ値を得られる。この中から正解のハッシュ値を探すのはgrepコマンドですね。ctf-player@pico-chall$ sha256sum ./files/*|grep fba9f49bf22aa7188a155768ab0dfdc1f9b86c47976cd0f7c9003af2e20598f7としたら該当ファイルがヒットする。それを./decrypt.shにかければ終了。

CanYouSee

How about some hide and seek? Download this file here.
ということで、画像が渡された。初手しますか。

└─# file ukn_reality.jpg
ukn_reality.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, baseline, precision 8, 4308x2875, components 3

└─# strings ukn_reality.jpg |grep pico

└─# binwalk ukn_reality.jpg

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             JPEG image data, JFIF standard 1.01

あらかたはやったが特に異常なし。 (Aperi'Solve)にぶち込んだ。steghideに反応あり、そして、stringsコマンドのところが少し気になる。grepしないでやるべきだった。

└─# steghide extract -sf ukn_reality.jpg
Enter passphrase:
wrote extracted data to "flag".

抽出できた。The flag is not here maybe think in simpler terms. Data that explains data.だそうです。違う。stringsを見る。

└─# strings ukn_reality.jpg | head -n 20
JFIF
7http://ns.adobe.com/xap/1.0/
<?xpacket begin='
' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 11.88'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
 <rdf:Description rdf:about=''
  xmlns:cc='http://creativecommons.org/ns#'>
  <cc:attributionURL rdf:resource='cGljb0NURntNRTc0RDQ3QV9ISUREM05fM2I5MjA5YTJ9Cg=='/>
 </rdf:Description>
</rdf:RDF>
</x:xmpmeta>

最初らへんに何かしらのコードが書かれている。
気になるのは中断の==で終わるrdf:resourceである。これをcyberchefに入れたらflag出てきた。終了。

Secret of the Polyglot

The Network Operations Center (NOC) of your local institution picked up a suspicious file, they're getting conflicting information on what type of file it is. They've brought you in as an external expert to examine the file. Can you extract all the information from this strange file? Download the suspicious file here.
ということでPDF形式のファイルを渡された。解析していく。

flag2of2-final.pdf: PNG image data, 50 x 50, 8-bit/color RGBA, non-interlaced

pdfと思いきやpng画像のようだ。stringsでそれらしい文字列がないかをgrepしたがなさそう。hexdump -v -C flag2of2-final.pdfをしてみると下らへんに可読文字がたくさんあった。これといってわからない。よくはわからない。さて、まず、拡張子をpngに変えてみてみるとflagらしきものが見えた。picoCTF{f1u3n7_ 画像系で疑うはステガノグラフィーである。binwalkしてみる。

└─# binwalk flag2of2-final.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 50 x 50, 8-bit/color RGBA, non-interlaced
914           0x392           PDF document, version: "1.4"
1149          0x47D           Zlib compressed data, default compression

何かしらのpdfが埋め込まれている。抽出してみてみるとなんかflagのかけらのようなものが見える。繋げたらflagだった終了。

Mob psycho

Can you handle APKs? Download the android apk here.
ということで、ファイルが渡された。初手をしましょう。

└─# file mobpsycho.apk
mobpsycho.apk: Zip archive data, at least v1.0 to extract, compression method=store

zip形式のようだ。stringsコマンドではいい感じのものはなかった。

知識(android apk)

android apk

(APKファイル)を参考にした。アンドロイドのアプリのインストールするのはこれをインストールしているようだ。そんあファイル。

grepコマンドでいろいろ探したがなさそう。flagをキーにしたらres/colorというところにflag.txtあり。それをcyberchefに投げたら終了。

Dear Diary

If you can find the flag on this disk image, we can close the case for good! Download the disk image here.

初手は初手です。

└─# file disk.flag.img
disk.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0x26,94,56), startsector 2048, 614400 sectors; partition 2 : ID=0x82, start-CHS (0x26,94,57), end-CHS (0x47,1,58), startsector 616448, 524288 sectors; partition 3 : ID=0x83, start-CHS (0x47,1,59), end-CHS (0x82,138,8), startsector 1140736, 956416 sectors

3つのセクタに分かれているようだ。

└─# mmls disk.flag.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000616447   0000614400   Linux (0x83)
003:  000:001   0000616448   0001140735   0000524288   Linux Swap / Solaris x86 (0x82)
004:  000:002   0001140736   0002097151   0000956416   Linux (0x83)

オフセットが分かった。

└─# fls disk.flag.img -o 2048
d/d 11: lost+found
r/r 13: ldlinux.sys
r/r 14: ldlinux.c32
r/r 16: config-virt
r/r 17: vmlinuz-virt
r/r 18: initramfs-virt
l/l 19: boot
r/r 21: libutil.c32
r/r 20: extlinux.conf
r/r 22: libcom32.c32
r/r 23: mboot.c32
r/r 24: menu.c32
r/r 15: System.map-virt
r/r 25: vesamenu.c32
V/V 76913:      $OrphanFiles

└─# fls disk.flag.img -o 616448
Cannot determine file system type

└─# fls disk.flag.img -o 1140736
d/d 32513:      home
d/d 11: lost+found
d/d 32385:      boot
d/d 64769:      etc
d/d 32386:      proc
d/d 13: dev
d/d 32387:      tmp
d/d 14: lib
d/d 32388:      var
d/d 21: usr
d/d 32393:      bin
d/d 32395:      sbin
d/d 32539:      media
d/d 203:        mnt
d/d 32543:      opt
d/d 204:        root
d/d 32544:      run
d/d 205:        srv
d/d 32545:      sys
d/d 32530:      swap
V/V 119417:     $OrphanFiles

となっている。3番目のやつにflagがありそうですね。簡単にgrepでflagらしきものを調査したが、なさそう。 autopsyで見ていく。といっても簡単にはできなさそう。400点ですもんね。
でも、root配下にあるものは何やら手掛かりになりそう。

└─# fls -r disk.flag.img 204 -o 1140736
r/r 1837:       .ash_history
d/d 1842:       secret-secrets
+ r/r 1843:     force-wait.sh
+ r/r 1844:     innocuous-file.txt
+ r/r 1845:     its-all-in-the-name

innocuous-file.txtが気になるが0byteである。削除されているようだ。

└─# icat disk.flag.img 1837 -o 1140736
ls -al ..
./force-wait.sh

force-wait.shが実行されている。

└─# icat disk.flag.img 1843 -o 1140736
#!/bin/ash

sleep 10

10秒間止まるだけ。関係あるのだろうか？its-all-in-the-nameとinnocuous-file.txtは何も表示されなかった。ログを確認してみる。/var/log/messageには起動した形跡が2回あっただけで不審なのはない。(Linux Forensics)を参考にファイルを見ていく。

タイムライン解析を行っているが、いまいち中身にたどり着けない。rootのsecretディレクトリへのアクセスが行われているが、どのような内容化までは把握できない。
writeUpを確認した( picoCTF 2024 - Writeup)。ジャーナルファイルがあることを気にしていた。なにか聞いたことある。

知識(USNジャーナル)

USNジャーナル

(USNジャーナル解析の追求)を参考にした。「ファイル/フォルダに対する変更処理を記録」だそうだ。

よくNTFS ファイルシステムでも$Jファイルを解析することがあるが、これは変更内容を記録していたのね。それがwindowsだけでなくlinuxのファイルシステムにも同様にあるようだ。初知り。

└─# fsstat -t disk.flag.img -o 2048
ext4

ext4 ファイルシステムでのジャーナルを見れば答えにたどりつけるようだ。難しい。

└─# icat disk.flag.img -o 1140736 8 | cat | grep innocuous-file.txt -a
�x���� ����������՚�e���2
                        .�
force-wait.sh4�innocuous-file.txt
��                               ��`I
  ]�epysepyse/bin/busybox�mE�� B�� n�� n��!cpyse� n���
                                                      pysepysepyse/bin/busyboxO}���O �
                                                                                      � n�� n�� n�pyse� n���
                                                                                                            pysepysepyse/bin/busybox��O�z^ �*� n�� n�� n�pyse� n���
                                           ��epysepyse/bin/busybox      �;��� Ǆ� n�� n�����pyse� n��;9�ٻ�|e��9p�"�;9� ��~��
�x���� ����������՚�e���2
                        .�
force-wait.sh4innocuous-file.txt5�original-filename
                                                   �]����;9�!�Ǧe��4��I�;9�")���㋀��^�e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh48innocuous-file.txt5�pic
                                      މ�Gɤ���e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4innocuous-file.txt5�oCT
                                     �7�#����e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4(innocuous-file.txt5�F{1
                                      �j�Tn����e�e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4innocuous-file.txt5�_53
                                     ��c�^����eD�e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4(innocuous-file.txt5�3_n
                                      ޤ������e]�e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4innocuous-file.txt5�4m3
                                     ��|␦�����ev�e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4(innocuous-file.txt5�5_8
                                      ޭ�B����e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4innocuous-file.txt5�0d2
                                     �'�;�����e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4(innocuous-file.txt5�4b3
                                      ބ�3g����e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4innocuous-file.txt5�0}
                                    �1�"����e��e��e
�x���� ����������՚�e���2
                        .�
force-wait.sh4(innocuous-file.txt5�its-all-in-the-name
                                                      �f�⤁��e�e��e

force-wait.sh48innocuous-file.txt5�の後ろにflagのようなものが見れる。これをつなげばflagのようだ。終了。

感想

windowsでも$Jを解析したことがある。それの役割を理解していればそれをlinuxでも探せばいいというように考えればよかった。つまり、linuxにもprefetchのようなものもあると考えれるかもしれない。

ここ以降未解決

File types

This file was found among some files marked confidential but my pdf reader cannot read it, maybe yours can. You can download the file from here.という言葉とともにpdfファイルを渡された。

初手はfile,stringsコマンド
　シェルで実行するようなファイルのようだ。

知識

シェルスクリプト

Linux】.shファイルとは？実行方法とシェルスクリプトの記述について

とりあえず実行してみる。
実行したら手に入るみたいな簡単なものではなさそう。仕様をちゃんと理解することが大切そう。よく見てみていたらもしかしたら、渡されたファイルに何かしら埋め込まれているのではないかと思った。 binwalkしてみる。抽出をやってみたが抽出できない。何かしら制限されているのかも？
　ここで実行したときの出力から何かのdirectoryを作ってることがわかる。もし先に作っておくと画像のような出力になった。
つまり、x-は実行したことを表していると考えられる。そして、実行されているのは

ロックディレクトリ(_sh0046)を作る
flagを抽出する。
作ったディレクトリを削除

となっているようだ。抽出の時には実行したファイルの中のuudecodeを調べている。そして、flagを保存できず。MD5チェックも失敗している。

知識

MD5

ハッシュ関数であるMD5を通して出力される値。 MD5チェックサム

ここまではわかったがこれ以降手詰まり。hintsを拝見。Remember that some file types can contain and nest other files.つまり、ファイル形式によって入れ子でファイルを作れるということ？逆に言えば、pdfファイル形式ではそれを表せていないということ？でも、埋め込まれているのなんか前もあったはずや。
んーって感じです。ちと、writeup見てみた。uudecodeというものに注目していた。いわれてみれば引っかかっていた。(uudecodeについて)。なにやら、そういうツールのようだ。(uudecodeインストール) uudecodeをインストールしたのちに実行したらflagファイルが現れた。(ほかのファイルは拡張子を変えればよいと考えいろいろ変えていた残骸です。)さて、出てきたflagファイルにfileコマンド。

arアーカイブだそうだ。これをどうするんや？arについて調べる。

知識

arについていろいろ書いてる。 ar - 静的なライブラリファイルを作成する

というわけで、ar x flagでアーカイブを展開。そうすると何も変化なし！？もう一度flagファイルにfileコマンド。

cpioアーカイブというものになっている。
この問題はまだまだ続きそうです。
[2023/08/21]

UnforgottenBits

Download this disk image and find the flag.ということで、いつもの初手。

└─# file disk.flag.img
disk.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0xc,223,19), startsector 2048, 204800 sectors; partition 2 : ID=0x82, start-CHS (0xc,223,20), end-CHS (0x2d,130,21), startsector 206848, 524288 sectors; partition 3 : ID=0x83, start-CHS (0x2d,130,22), end-CHS (0x82,138,8), startsector 731136, 1366016 sectors

└─# mmls disk.flag.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000206847   0000204800   Linux (0x83)
003:  000:001   0000206848   0000731135   0000524288   Linux Swap / Solaris x86 (0x82)
004:  000:002   0000731136   0002097151   0001366016   Linux (0x83)

└─# fls disk.flag.img -o 2048
d/d 11: lost+found
r/r 12: ldlinux.sys
r/r 13: ldlinux.c32
r/r 15: config-virt
r/r 16: vmlinuz-virt
r/r 17: initramfs-virt
l/l 18: boot
r/r 20: libutil.c32
r/r 19: extlinux.conf
r/r 21: libcom32.c32
r/r 22: mboot.c32
r/r 23: menu.c32
r/r 14: System.map-virt
r/r 24: vesamenu.c32
V/V 25585:      $OrphanFiles

└─# fls disk.flag.img -o 731136
d/d 7130:       home
d/d 11: lost+found
d/d 12: boot
d/d 7121:       etc
d/d 7122:       proc
d/d 7123:       dev
d/d 7124:       tmp
d/d 7125:       lib
d/d 7126:       var
d/d 7127:       usr
d/d 7128:       bin
d/d 7129:       sbin
d/d 7131:       media
d/d 7132:       mnt
d/d 7133:       opt
d/d 7134:       root
d/d 7135:       run
d/d 7136:       srv
d/d 7137:       sys
d/d 2349:       swap
V/V 42721:      $OrphanFiles

という感じでpicoCTFではよくある形というった感じ。一応、homeとrootを確認。

└─# fls -r disk.flag.img 7130 -o 731136
d/d 24: yone
+ r/r 2362:     .ash_history
+ d/d 2364:     notes
++ r/r 2365:    1.txt
++ r/r 2366:    2.txt
++ r/r 2408:    3.txt
+ d/d 2360:     Maildir
++ d/d 2368:    new
+++ r/r 2369:   1673722272.M424681P394146Q14.haynekhtnamet
++ d/d 2370:    tmp
++ d/d 2371:    cur
+++ r/r 2372:   1673722272.M354727P394146Q3.haynekhtnamet:2,S
+++ r/r 2373:   1673722143.M758346P394112Q1.haynekhtnamet:2,S
+++ r/r * 2362(realloc):        1673722272.M376010P394146Q6.haynekhtnamet:2,S
+++ r/r 2375:   1673722272.M418711P394146Q13.haynekhtnamet:2,S
+++ r/r 2376:   1673722272.M362142P394146Q4.haynekhtnamet:2,S
+++ r/r 2377:   1673722272.M413082P394146Q12.haynekhtnamet:2,S
+++ r/r 2378:   1673722272.M388674P394146Q8.haynekhtnamet:2,S
+++ r/r 2379:   1673722272.M382945P394146Q7.haynekhtnamet:2,S
+++ r/r 2380:   1673722272.M406783P394146Q11.haynekhtnamet:2,S
+++ r/r 2381:   1673722272.M394284P394146Q9.haynekhtnamet:2,S
+++ r/r * 2410: 1673722272.M350117P394146Q2.haynekhtnamet:2,S
+++ r/r * 2411: 1673722272.M400456P394146Q10.haynekhtnamet:2,S
+++ r/r 2384:   1673722272.M345699P394146Q1.haynekhtnamet:2,S
+++ r/r 2385:   1673722272.M370158P394146Q5.haynekhtnamet:2,S
+ d/d 2374:     irclogs
++ d/d 2382:    01
+++ d/d 2383:   04
++++ r/r 2386:  #avidreader13.log
++ d/d 2387:    02
+++ d/d 2388:   09
++++ r/r 2389:  #leagueoflegends.log
+++ d/d 2390:   07
++++ r/r 2391:  #leagueoflegends.log
+++ d/d 2392:   25
++++ r/r 2393:  #leagueoflegends.log
+++ d/d 2394:   17
++++ r/r 2395:  #leagueoflegends.log
+++ d/d 2396:   04
++++ r/r 2397:  #leagueoflegends.log
++ d/d 2398:    07
+++ d/d 2399:   17
++++ r/r 2400:  #common.log
+ d/d 2401:     .lynx
++ r/r 2402:    browsing-history.log
+ d/d 2403:     gallery
++ r/r 2404:    2.bmp
++ r/r 2405:    3.bmp
++ r/r 2406:    7.bmp
++ r/r 2407:    1.bmp

└─# fls -r disk.flag.img 7134 -o 731136
r/r 2356:       .ash_history

rootの履歴も気になるけど、homeの.bmpも気になる。
ここからはautopsyを用いて調査していく。 rootの履歴はいいものがなかったので、homeを見てみる。

irclogs : 会話形式のログ
maildir : メールのやり取りのようなもの(cur,new)
.lynx : browsing-history.log
gallery : bmp拡張子の画像が4枚。
notes : txt形式のものが3つ。書かれている意味は分からない。

ここからの方針

フォレンジックのようあるのは画像からflagを見つけること。
メール内容の調査。
ログの調査
ブラウザー履歴の調査

この4つで考えていく。・フォレンジックのよくあるのは画像からflagを見つけること。
まずはbinwalkをしていく。

└─# binwalk 1.bmp

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PC bitmap, Windows 3.x format,, 1024 x 1024 x 24

└─# binwalk 2.bmp

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PC bitmap, Windows 3.x format,, 1024 x 1024 x 24

└─# binwalk 3.bmp

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PC bitmap, Windows 3.x format,, 1024 x 1024 x 24
374391        0x5B677         ZBOOT firmware header, header size: 32 bytes, load address: 0x3E463E43, start address: 0x393F453C, checksum: 0x3F373840, version: 0x333D3337, image size: 808466480 bytes
973590        0xEDB16         HPACK archive data
1004337       0xF5331         HPACK archive data
1007406       0xF5F2E         HPACK archive data
1047390       0xFFB5E         HPACK archive data
1188423       0x122247        ZBOOT firmware header, header size: 32 bytes, load address: 0x3840393C, start address: 0x27303830, checksum: 0x1D16262E, version: 0x050D0515, image size: 768 bytes
2483766       0x25E636        ZBOOT firmware header, header size: 32 bytes, load address: 0x3C423940, start address: 0x30373D34, checksum: 0x32283238, version: 0x2A30272E, image size: 606613029 bytes
2508345       0x264639        ZBOOT firmware header, header size: 32 bytes, load address: 0x3D433A42, start address: 0x31383E35, checksum: 0x332A3539, version: 0x292F262D, image size: 572992804 bytes

└─# binwalk 7.bmp

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PC bitmap, Windows 3.x format,, 1024 x 1024 x 24
1108489       0x10EA09        Intel x86 or x64 microcode, sig 0x24054525, pf_mask 0xe023317, 1C08-09-34, rev 0x1e0e0105, size 262656

3と7から抽出できそう。まずは7から。

└─# binwalk -D='.*' 7.bmp --run-as=root

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PC bitmap, Windows 3.x format,, 1024 x 1024 x 24
1108489       0x10EA09        Intel x86 or x64 microcode, sig 0x24054525, pf_mask 0xe023317, 1C08-09-34, rev 0x1e0e0105, size 262656

実行したが、直接的なflagはなさそう。次に3。

└─# binwalk -D='.*' 3.bmp --run-as=root

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PC bitmap, Windows 3.x format,, 1024 x 1024 x 24
374391        0x5B677         ZBOOT firmware header, header size: 32 bytes, load address: 0x3E463E43, start address: 0x393F453C, checksum: 0x3F373840, version: 0x333D3337, image size: 808466480 bytes
973590        0xEDB16         HPACK archive data
1004337       0xF5331         HPACK archive data
1007406       0xF5F2E         HPACK archive data
1047390       0xFFB5E         HPACK archive data
1188423       0x122247        ZBOOT firmware header, header size: 32 bytes, load address: 0x3840393C, start address: 0x27303830, checksum: 0x1D16262E, version: 0x050D0515, image size: 768 bytes
2483766       0x25E636        ZBOOT firmware header, header size: 32 bytes, load address: 0x3C423940, start address: 0x30373D34, checksum: 0x32283238, version: 0x2A30272E, image size: 606613029 bytes
2508345       0x264639        ZBOOT firmware header, header size: 32 bytes, load address: 0x3D433A42, start address: 0x31383E35, checksum: 0x332A3539, version: 0x292F262D, image size: 572992804 bytes

└─# strings 5B677 | grep pico
xo}vo{yo}vn|umztlyrlyrlyrjxqjxqjxqiwplyrlyrlyrlyrlxqlxqlyrlxqlxqlxqlxqlxqiwpkvpjuoitnhsmhsmhtkeqjgrkbpicofbmgalf^jb\ga\ga[f`[f`[f`[f`[f`[f`[f`[f`^i^\h_\ga[f`[f`[f`[f`[d\[d\Yc[Yc[XbZYc[XbZWaXWbWWaXWaXWaXWaXV`WV`WV`WV`WU^VU^VU^VV`WU^VU^VT]UT]UR\TR\TQ[SQ[SPZQPZQPZQPZQRYQPZQPZQPZQOYPNWOMVNKUMJUJHRHFPEFPEDODBMB@J??I>:F>9F;7D85E70?4.<3@OJ

picoという文字があるのは5B677、EDB16に見られた。でもあまりよさげなのはない。まだ難しいようだ。他の問題を解いてから行おうと思う。

St3g0

Download this image and find the flag. 画像が渡されている。そこからflagを探す。
見ただけではすぐには見るからない。画像系の問題よくわからぬ。

Milkslap

(🥛)というURLに飛ばされる。そこでは男性が牛乳をかけられている動画が流れている。

なんも思いつかない。フォレンジックなのだろうか。多分ステガノ系だと思う。後回し。

Very very very Hidden

Finding a flag may take many steps, but if you look diligently it won't be long until you find the light at the end of the tunnel. Just remember, sometimes you find the hidden treasure, but sometimes you find only a hidden map to the treasure.といことでやっていく。

IPv6のプロトコルも少なからずあるがIPv4が大半。UDPよりTCPが多い。UDPの方が気になっています。

エンドポイントは多い。複数人がやり取りしているのだろうか？

192.168.1.189が複数ポートで多くやり取りしているのが目立つ。443portが多いのも気になる。

知識(443ポート)

443ポート

(「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典)を参考にした。HTTPSの通信が行われるときに使用されるポートのようだ。

つまり、HTTPS通信が多く行われているようだ。中身見れるのだろうか？tcp.port == 443でフィルタしたら、やはりTLSv1.3で通信が行われているので中身は見れそうにない。そこでふと見ていると、httpでデータをやり取りしてるのが目についた。

こっちの方が一連のやり取りが分かりやすい。

/NothingSus/httpではHelloという言葉しか受け取っていない。
/favicon.ico HTTPは404not Foundということで何も受け取っていない
/NothingSus/duck.png では画像を受け取っている。
/NothingSus/evil_duck.png でも画像を受け取っている。
/では特に何も受け取っていない。

知識(HTTPステータスコード一覧)

HTTPステータスコード一覧

(HTTPステータスコード一覧とリクエストとレスポンスの意味を解説)を参考にした。クライアントエラーや300のリダイレクトなどは知っておくとためになると思った。

オブジェクトをエクスポートでhttpを選択し、duck.pngとevil_duck.pngを抽出した。ここから、ヒントを抽出するのだと考えられる。画像系の問題は苦手。他の画像系の問題を解いてから再度しようか迷うレベルで苦手。
こちらがduck.png

こちらがevil_duck.pngである。 evil_duck.pngの方がぼやけているので、何からの情報が埋め込まれているように感じる。
fileとstringsコマンドでもめぼしい情報はなさそう。

└─# binwalk evil_duck.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 1223 x 812, 8-bit/color RGB, non-interlaced
2862          0xB2E           Zlib compressed data, compressed

binwalkすると圧縮データありそう。

└─# binwalk duck.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 1223 x 812, 8-bit/color RGB, non-interlaced

ちなみにduck.pngを見てみると圧縮データがないので、やはり怪しい。

└─# file B2E-0
B2E-0: zlib compressed data

ということで圧縮データを抽出できた。ここで気になったのが、pngにはそもそもzlibが入っているのではないかということ。

知識(pngとzlib)

pngとzlib

(PNG を読んでみた)を参考にした。pngは圧縮されたものをIDATチャンクに含んでいるようだ。

つまり、今回の画像もただ画像の圧縮データが入っているだけではないのだろうか？でも、圧縮しているのにサイズが大きくなっているのは気になる。
0.pngとB2E-0を比較しても、少し圧縮されているのということは、やはりそもそも何かしら埋め込まれいると考えるのがよさそう。(CTFにおけるステガノグラフィ入門とまとめ)を参考に何かできないかを探った。(Aperi'Solve)に画像を入れてみた。
と結果が出た。下の方にはこれといった情報はないように思ったが、passwordにHelloとあるのが気になる。最初のHTTp通信の内容もHelloだったのでパスワードとなるのは合点がいく。
しかし、このパスはどこで使うのかはわからない。TLS通信とQUIC通信が暗号化されているようだ。

知識(QUIC)

QUIC

(QUICプロトコルとは？次世代プロトコルのメリットと使い方を解説)を参考にした。UDPを安全に高速にするためのプロトコルのようだ。

少し迷走する。 54.147.39.126と192.168.1.189ではhttp通信以外に多量の80ポートと53177ポートのやり取りがある。しかし、重要そうなのはhttp通信での画像のやり取りっぽい。tlsやquicの復号には(WiresharkでのQUICの復号(decrypt))からkeylogファイルやTLSでは秘密鍵が必要である。

もう少し、抽出した画像を調べるのがよさそう。

知識(favicon.ico)

(「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典)を参考にした。ホームページのアイコンのようだ。

favicon.icoを欲していたので、最初から画像を欲しているようだ。
探しているときに先とは違いip.addr == 104.21.2.183にGET /HTTPリクエストをしている。

しかし、手に入らない(存在しない)と分かった後に、443ポートでやり取りしている。つまり、80パートではなく443ポートに移動していたということだろうか。

また、ここで、powershellという言葉が出ていることに気づいた。あまり有益な情報はなさそう。 DNS系のログを眺めているが、あまり重要そうでない。

TLSを復号するためには秘密鍵かpre-master-secretが必要なようだ。 QUICを復号するにはkeylogが必要なようだ。
この事から、パケットからこれらを生成できないかを目標に取り組んでいる。 QUICではchromeが関係しているようだ。(WiresharkでのQUICの復号(decrypt))

一日おいて考えたことは今までに見たことのないQUIC通信は気になる。また、2枚の画像は相変わらず気になる。
ここでhintsを2みた。

I believe you found something, but are there any more subtle hints as random queries?
The flag will only be found once you reverse the hidden message.

であった。ランダムクエリはあっただろうか？また、2番は隠されたメッセ―ジをリバースして見れるようだ。わからぬ。 writeup(picoCTF2021 [Forengics] writeup)を見た。powershellのステガノグラフィーがキーだったようだ。何かしらのツールを入れるとできるようだ。あんまりわからないので今回は保留で。

反省

ぶっちゃけ、画像系の問題は苦手だ。powershell関係のログがあるのは気が付いているがそこからステガノグラフィーとの関係に持っていく発想は難しい。また、ツールも複数ある中で探すのも難しい。パケットの方に注視していたので、潔くwriteup見てよかった。あのまま続けていても答えは出なかっただろう。画像系を進めるか、ほかの問題を進めるかは悩ましい。

endianness-v2

Here's a file that was recovered from a 32-bits system that organized the bytes a weird way. We're not even sure what type of file it is. Download it here and see what you can get out of it
ということでよくわからないファイルが渡された。

└─# file challengefile
challengefile: data

特になし。

└─# strings challengefile
 '.$
#,")7(
410,'
4428=943.<
!2222222222222222222222222222222222222222222222222
)('&654*:987FEDCJIHGVUTSZYXWfedcjihgvutszyxw
5*)(9876EDC:IHGFUTSJYXWVedcZihgfutsjyxwv
H%..
PEIZn
Zm}m!aJ
bzh\
[JRd
8YQi
sr.PE
i>X[
Aeyv
l\gJQ
^z,Z
75WX
 uWIU
a{!x
4erk7
O;$!
z<YY
W[.7
R=+k
f5os
ih{I[
[jc4
Vrcn
-oeb
YI0K
[J&c
aJ"+
-       d;

最初らへんが少し気になるがこんな感じ。