Little - SuSeC CTF 2020 Forensics writeup
Autopsyの無料トレーニングを終えていい気分でいたものの、書いておきたいwriteupが貯まりに溜まりまくってるこの頃。
今回は、2020/03/15 15:30 ~ 2020/03/17 03:30 (JST) に行われた「SuSeC CTF 2020」の「Little」をお届けする。
Little
A little boy is playing around in his grandfather's attic, where he finds a magical box. Help him discover what is in the box.
ATTENTION: The flag that you are going to capture for this task does not contain the word SUSEC{, but you have to add this word to the beginning of the discovered flag before submitting it.
与えられたファイル「little.img_03551d5d361ae5f58675f065da899e9f6e9e3361.txz」を見ていく。
# file little.img_03551d5d361ae5f58675f065da899e9f6e9e3361.txz little.img_03551d5d361ae5f58675f065da899e9f6e9e3361.txz: XZ compressed data # rm little.img # tar -Jxvf little.img_03551d5d361ae5f58675f065da899e9f6e9e3361.txz little.img # file little.img little.img: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, reserved sectors 2048, root entries 512, sectors 8192 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 5, sectors/track 32, heads 64, serial number 0xe318769f, unlabeled, FAT (12 bit)
ディスクイメージのようなので、sleuth kit で見ていく。
# img_stat little.img IMAGE FILE INFORMATION -------------------------------------------- Image Type: raw Size in bytes: 67108864 Sector size: 512 # mmls little.img Cannot determine partition type # fsstat -i raw little.img Cannot determine file system type (EXT2/3/4 or FAT)
sleuth kitさんがおっしゃるには、「これ、EXT2/3/4かFATじゃね」ということ。とりあえず、EXTで見てみる。
# fls -i raw -f ext little.img -/r 25: secondf.png V/V 49: $OrphanFiles # icat -i raw -f ext little.img 25 > secondf.png # file secondf.png secondf.png: PNG image data, 1024 x 300, 8-bit/color RGB, non-interlaced
「secondf.png」というファイルが出てきましたね。secondということは、何か手順を飛ばした？
このpngを見てみるとflagのようなものが書いてあるが、
次は「FAT」で見てみる。
# fls -i raw -f fat little.img r/r 3: FIRSTF.KGB v/v 98147: $MBR v/v 98148: $FAT1 v/v 98149: $FAT2 V/V 98150: $OrphanFiles # icat -i raw -f fat little.img 3 > FIRSTF.KGB # file FIRSTF.KGB FIRSTF.KGB: KGB Archiver file with compression level 3
「FIRSTF.KGB」と、おそらくflagの始めの部分ぽいものを発見した。
ここで、kgbとは wikiへ
KGB Archiver - Wikipedia
圧縮？ファイルということで、7-zipを試す。
# 7za x FIRSTF.KGB 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=ja_JP.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (806E9),ASM,AES-NI) Scanning the drive for archives: 1 file, 196401 bytes (192 KiB) Extracting archive: FIRSTF.KGB ERROR: FIRSTF.KGB Can not open the file as archive Can't open as archive: 1 Files: 0 Size: 0 Compressed: 0
あの7-zipが対応していないなんてあるのかと思いつつ、これはおそらく知識の不足で勘違いな部分もあると思うので深く言及しない。
kgbアーカイバが必要なようなので、導入して利用。
# kgb FIRSTF.KGB Extracting archive KGB_arch -3 FIRSTF.KGB ... 191KB firstf.ogg: equal 191KB -> 191KB w 0.54s. (99.99% czas: 363 KB/s) # file firstf.ogg firstf.ogg: Ogg data, Opus audio, # mpv firstf.ogg (+) Audio --aid=1 (opus 1ch 48000Hz) AO: [pulse] 48000Hz mono 1ch float A: 00:00:24 / 00:00:24 (98%) Exiting... (End of file)
kgbからは「firstf.ogg」が出てきて、この音声ファイルをとりあえず再生してみると「c0me_wi4h_f4t_m4n_」とflagが聞こえてきた。
お次は、「thirdf」だが。ここまで、mmlsでパーティションが確認できなかったにも関わらずsleuth kitのお声に従うと「EXT」と「FAT」があった。何となく、「thirdf」も同じようにありそうな気がしつつ、何か手がかりが無いかと思いつつ、stringsで探索する。
# strings little.img | grep "thirdf" thirdf.mp4 thirdf.mp4
目的の「thirdf」は、「thirdf.mp4」として存在しているらしい。
さあ、ここからどうするかと「
Forensics toolのまとめ(windows多め)最終更新2020/04/06 - 4ensiX」を
眺めていると、「testdisk」が目に入ったので利用する。
# testdisk little.img
最初に[Proseed] を選択、パーティションは分からなかったので [None] 、 そして次のところでqを押して[Analyze]を選択する。[Quick Search] -> Enter(ext2のやつを選択) -> [Deeper Search]すると、三つのパーティションが現れる。
とりあえず、「P」で各々のパーティションのファイルを見てみると、
何となく、上手くファイルカービングする必要があるのだろうけれど、どうすればいいか。と思いつつ、ファイル修復屋さんの「photorec」に助けを求めてみる。
# photorec little.img
[Proceed] を選択してから、「Unknown」と「ext2」が見える。ここは、先のtestdiskの結果から「ext2」で見れば「thirdf.mp4」に出会えそうな気がするので「ext2」を選択。「Free」と「Whole」の選択があるがどうすればいいか分からない。
選択後に、出力したいディレクトリ内で「C」を選択すると出てくる。
「photorec」が頑張ってカービングした結果が、選択したディレクトリ内のrecup_dir*という名前のディレクトリに出力される。
~/recup_dir.1# ls f0000000.fat f0008432.mp4 report.xml
まず、出てきた「f0000000.fat」は、binwalkに通すことで、
# binwalk f0000000.fat DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 519168 0x7EC00 KGB archive
kgbアーカイブが含まれることを確認した。これたぶん「FIRSTF.KGB」だと思われる。
また、「f0008432.mp4」を再生したところ。
# mpv f0008432.mp4 (+) Video --vid=1 (*) (h264 1400x188 15.000fps) VO: [gpu] 1400x188 yuv444p V: 00:00:08 / 00:00:08 (99%) Dropped: 1 Exiting... (End of file)
flag: SUSEC{c0me_wi4h_f4t_m4n_t0_7he_3nd_0f_t4i3_sUsEc_journey}
追想
binwalkからのアプローチ
他の方のやり方を見ると、始めのアプローチとしてbinwalkを利用するケースが見られた。しかし、自分の環境とその人の環境では何が違うのか分からないが表示結果が違った。
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Linux EXT filesystem, rev 1.0, ext2 filesystem data, UUID=e0676215-9cc7-abbd-f840-953aacffacff 1160 0x488 Unix path: /home/susec/yoursearching/name_is/junk 279112 0x44248 Unix path: /home/susec/yoursearching/name_is/littleBoy.img 524288 0x80000 Linux EXT filesystem, rev 1.0, ext2 filesystem data, UUID=e0676215-9cc7-abbd-f840-953aacffacff 532480 0x82000 PNG image, 1024 x 300, 8-bit/color RGB, non-interlaced 532754 0x82112 Unix path: /www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:dc="http:// 535150 0x82A6E Zlib compressed data, default compression 1072128 0x105C00 KGB archive 66601544 0x3F84248 Unix path: /home/susec/yoursearching/name_is/littleBoy.img 66863688 0x3FC4248 Unix path: /home/susec/yoursearching/name_is/littleBoy.img
ここまで、binwalkで辿り着けるらしい。
「thirdf.mp4」の別方法？のカービング
autopsy(使用ver.4.14.0)で、「litlle.img」を開くと、「$Carvedfile」に「f0008432.mp4」を確認した。
このとき「little.img」は、データソースのタイプとして「未使用領域のイメージファイル(Unallocated)」として読み込み、「インジェストモジュール(injest module)」の「PhotoRec Carver」の利用を忘れない。
