4ensiX

4ensiX

Forensics専門でなければ、CTFはDFIRの勉強にほとんど役立たないことをを知ったこの頃

Little - SuSeC CTF 2020 Forensics writeup

Autopsyの無料トレーニングを終えていい気分でいたものの、書いておきたいwriteupが貯まりに溜まりまくってるこの頃。
今回は、2020/03/15 15:30 ~ 2020/03/17 03:30 (JST) に行われた「SuSeC CTF 2020」の「Little」をお届けする。

ctftime.org

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のようなものが書いてあるが、

f:id:Zarat:20200417034253p:plain
secondf.png
「tO_7h3_3nd_Of」となっており、中途半端なので「firstf」と「thirdf」がありそう。
次は「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]すると、三つのパーティションが現れる。

f:id:Zarat:20200417035644p:plain
testdiskで出てきた3つのパーティション
いや、パーティションて書いてあるけど何でsleuth kit で出てこないんやと思ったのは自分だけではないハズ(分からん)。
とりあえず、「P」で各々のパーティションのファイルを見てみると、
f:id:Zarat:20200417040008p:plain
一つ目のパーティション
f:id:Zarat:20200417040054p:plain
二つ目のパーティション
f:id:Zarat:20200417040154p:plain
三つ目のパーティション
三つ目だけ、何も出てこない。おそらく、ここに「thirdf.mp4」がありそうな気がする。
何となく、上手くファイルカービングする必要があるのだろうけれど、どうすればいいか。と思いつつ、ファイル修復屋さんの「photorec」に助けを求めてみる。

# photorec little.img

[Proceed] を選択してから、「Unknown」と「ext2」が見える。ここは、先のtestdiskの結果から「ext2」で見れば「thirdf.mp4」に出会えそうな気がするので「ext2」を選択。「Free」と「Whole」の選択があるがどうすればいいか分からない。

f:id:Zarat:20200417042315p:plain
photorec解析
「thirdf.mp4」が未割当なのかどうか分からない。でも、そもそも認識されていないなら未割当と考えていいのだろうか。とりあえず、「Free」でやってみる。
選択後に、出力したいディレクトリ内で「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)

f:id:Zarat:20200417220035p:plain
「f0008432.mp4」の再生の様子
↑図のように、flagの最後の部分が入力されるのを確認した。

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」の利用を忘れない。

f:id:Zarat:20200417222322p:plain
autopsyで「little.img」を開いてみた
サムネの大きさを大(Large)にしたら、flagが見える。
f:id:Zarat:20200417222527p:plain
サムネでflagが見えた
結局、photorecの力を借りてるけどね。sleuth kit でもできないもんかね。