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のようなものが書いてあるが、
「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]すると、三つのパーティションが現れる。
いや、パーティションて書いてあるけど何でsleuth kit で出てこないんやと思ったのは自分だけではないハズ(分からん)。
とりあえず、「P」で各々のパーティションのファイルを見てみると、
三つ目だけ、何も出てこない。おそらく、ここに「thirdf.mp4」がありそうな気がする。
何となく、上手くファイルカービングする必要があるのだろうけれど、どうすればいいか。と思いつつ、ファイル修復屋さんの「photorec」に助けを求めてみる。
# photorec little.img
[Proceed] を選択してから、「Unknown」と「ext2」が見える。ここは、先のtestdiskの結果から「ext2」で見れば「thirdf.mp4」に出会えそうな気がするので「ext2」を選択。「Free」と「Whole」の選択があるがどうすればいいか分からない。
「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)
↑図のように、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」の利用を忘れない。
サムネの大きさを大(Large)にしたら、flagが見える。
結局、photorecの力を借りてるけどね。sleuth kit でもできないもんかね。
UTCTF 2020 Forensics writeup
土, 07 3月 2020, 09:00 JST — 月, 09 3月 2020, 09:00 JST 2020/03/07 9:00 JST - 03/09 9:00に「zer0opsCTF 2020」の裏では、「UTCTF 2020」が行われておりました。ここで出題されたForesics問の話をする。とても易しくて分かりやすいものばかりであった。 ctftime.org
- 1 Frame per Minute
- Spectre
- Observe_Closely
- [basics]_forensics
- The Legend of Hackerman, Pt. 1
- The Legend of Hackerman, Pt. 2
- Zero
1 Frame per Minute
I recently received this signal transmission known as SSTV in a mode called Martian? This technology is all very old so I'm not sure what to do with it. Could you help me out?
与えられたファイルは、
# file signals.wav signals.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz
問題文を素直に受け取って良いのなら、SSTVでしょう。
SSTV
自分の場合は、RX-SSTVに再生した音声を聞かせて解いた。音が再生されると自動で録音してくれるが、雑音の少ないところでやりましょう。
flag: utflag{6bdfeac1e2baa12d6ac5384cdfd166b0}
Spectre
I found this audio file, but I don't think it's any song I've ever heard... Maybe there's something else inside?
与えられたファイルはコレ。
# file song.wav song.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
おそらく、Spectreというからにはスペクトログラムを見るのではということでaudacityで開く。
メニューを開いて、スペクトログラムに切り替えると。
flag: utflag{sp3tr0gr4m0ph0n3}
一体どうやって作ったのか......
Observe_Closely
A simple image with a couple of twists... 与えられたファイルを見る。
# file Griffith_Observatory.png Griffith_Observatory.png: PNG image data, 320 x 155, 8-bit/color RGBA, non-interlaced root@kali:~/CTF/UTCTF2020/UTCTF2020/Forensic/Observe_Closely# binwalk Griffith_Observatory.png DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 PNG image, 320 x 155, 8-bit/color RGBA, non-interlaced 41 0x29 Zlib compressed data, default compression 127759 0x1F30F Zip archive data, at least v2.0 to extract, compressed size: 2587, uncompressed size: 16664, name: hidden_binary 130500 0x1FDC4 End of Zip archive, footer length: 22
binwalkを使って見たのは、何となく問題文からそんな気がしたからである。ファイルカービングは何でも良いが、今回はbinwalk -e
でいく。
# binwalk -e Griffith_Observatory.png DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 PNG image, 320 x 155, 8-bit/color RGBA, non-interlaced 41 0x29 Zlib compressed data, default compression 127759 0x1F30F Zip archive data, at least v2.0 to extract, compressed size: 2587, uncompressed size: 16664, name: hidden_binary 130500 0x1FDC4 End of Zip archive, footer length: 22 # cd _Griffith_Observatory.png.extracted/ # ls 1F30F.zip 29 29.zlib hidden_binary
zipが暗号化されていなかった所為か、zipの中身も一緒に出ている。
# strings hidden_binary /lib64/ld-linux-x86-64.so.2 (snip) Ah, you H found meH utflag{2H fbe9adc2H ad89c71dH a48cabe9H 0a121c0}H (snip)
動かすのが怖かったので、stringsを走らせた。
flag: utflag{2fbe9adc2ad89c71da48cabe90a121c0}
[basics]_forensics
My friend said they hid a flag in this picture, but it's broken! Now that I think about it, I don't even know if it really is a picture...
彼らの考えるForensicsとは一体何なのか、今明らかになる!
そんなことどうでもいいので、とりあえず与えられたファイルを見ていく。
# file secret.jpeg secret.jpeg: UTF-8 Unicode text, with CRLF line terminators
それはjpegではなかった。
# cat secret.jpeg | head The Project Gutenberg EBook of The History of Don Quixote by Miguel de Cervantes This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.net Title: The History of Don Quixote
テキストファイルのようである。
# strings secret.jpeg | grep "utflag" utflag{fil3_ext3nsi0ns_4r3nt_r34l}
flag: utflag{fil3_ext3nsi0ns_4r3nt_r34l}
これが、彼らの考えるForensicsであった......
The Legend of Hackerman, Pt. 1
My friend Hackerman tried to send me a secret transmission, but I think some of it got messed up in transit. Can you fix it?
では、そのHackermanさんから与えられたファイルがこちら。
# file hackerman.png hackerman.png: data
たぶんpngヘッダー直す系問題。
# cp hackerman.png fix.png # hexedit fix.png
自分は「hexedit」派。 間違いない。PNGといえば、
89 50 4E 47 0D 0A 1A 0A
から始まるので、このように書き換える。
# file fix.png fix.png: PNG image data, 1192 x 670, 8-bit/color RGBA, non-interlaced
flag: utflag{3lit3_h4ck3r}
最近はこんなものもあるらしい
# python PCRT.py -v -i fix2.png ____ ____ ____ _____ | _ \ / ___| _ \_ _| | |_) | | | |_) || | | __/| |___| _ < | | |_| \____|_| \_\|_| PNG Check & Repair Tool Project address: https://github.com/sherlly/PCRT Author: sherlly Version: 1.1 [Detected] Wrong PNG header! File header: 000000000D0A1A0A Correct header: 89504E470D0A1A0A [Notice] Auto fixing? (y or n) [default:y] y [Finished] Now header:89504E470D0A1A0A [Finished] Correct IHDR CRC (offset: 0x1D): 812E23AF [Finished] IHDR chunk check complete (offset: 0x8) [Finished] Correct IDAT chunk data length (offset: 0x2A1D length: 2000) [Finished] Correct IDAT CRC (offset: 0x4A25): CB097594 (snip) [Finished] Correct IDAT chunk data length (offset: 0x15F245 length: 1E83) [Finished] Correct IDAT CRC (offset: 0x1610D0): 69353954 [Finished] IDAT chunk check complete (offset: 0x2A1D) [Finished] Correct IEND chunk [Finished] IEND chunk check complete [Finished] PNG check complete [Notice] Show the repaired image? (y or n) [default:n] y
直ったwow......
ヘッダーだけで解決しないときに良いかもしれない。
The Legend of Hackerman, Pt. 2
Ok, I've received another file from Hackerman, but it's just a Word Document He said that he attached a picture of the flag, but I can't find it...
またまたハッカーマンから何か来たようである。与えられたファイルがこちら。
# file Hacker.docx Hacker.docx: Microsoft Word 2007+
このようなOffice系ファイルやオープンドキュメント系ファイルは、とりあえずunzipして色々見てみることが多い。
# cp Hacker.docx Hacker.zip # unzip Hacker.zip Archive: Hacker.zip (snip) inflating: word/media/image97.png inflating: word/media/image102.png inflating: word/media/image96.png inflating: word/media/image101.png inflating: word/media/image95.png inflating: word/media/image100.png inflating: word/media/image88.png inflating: word/media/image58.png (snip) inflating: word/media/image27.png inflating: word/media/image26.png inflating: word/media/image25.png inflating: word/media/image24.png inflating: word/media/image169.jpeg inflating: word/media/image37.png (snip)
大量に出てきた画像ファイルが明らかに怪しい。
# cd word/media/ # ls image1.png image12.png image140.png image161.png image182.png image37.png image58.png image79.png image10.png image120.png image141.png image162.png image183.png image38.png image59.png image8.png image100.png image121.png image142.png image163.png image184.png image39.png image6.png image80.png image101.png image122.png image143.png image164.png image19.png image4.png image60.png image81.png image102.png image123.png image144.png image165.png image2.png image40.png image61.png image82.png image103.png image124.png image145.png image166.png image20.png image41.png image62.png image83.png image104.png image125.png image146.png image167.png image21.png image42.png image63.png image84.png image105.png image126.png image147.png image168.png image22.png image43.png image64.png image85.png image106.png image127.png image148.png image169.jpeg image23.png image44.png image65.png image86.png image107.png image128.png image149.png image17.png image24.png image45.png image66.png image87.png image108.png image129.png image15.png image170.png image25.png image46.png image67.png image88.png image109.png image13.png image150.png image171.png image26.png image47.png image68.png image89.png image11.png image130.png image151.png image172.jpeg image27.png image48.png image69.png image9.png image110.png image131.png image152.png image173.png image28.png image49.png image7.png image90.png image111.png image132.png image153.png image174.png image29.png image5.png image70.png image91.png image112.png image133.png image154.png image175.jpeg image3.png image50.png image71.png image92.png image113.png image134.png image155.png image176.png image30.png image51.png image72.png image93.png image114.png image135.png image156.png image177.png image31.png image52.png image73.png image94.png image115.png image136.png image157.png image178.png image32.png image53.png image74.png image95.png image116.png image137.png image158.png image179.png image33.png image54.png image75.png image96.png image117.png image138.png image159.png image18.png image34.png image55.png image76.png image97.png image118.png image139.png image16.png image180.png image35.png image56.png image77.png image98.png image119.png image14.png image160.png image181.png image36.png image57.png image78.png image99.png
仕方がないので、順番に見ていく。
すると、「image23.png」にてflag発見。
flag: utflag{unz1p_3v3ryth1ng}
Zero
This file seems to be too large given how much text it contains, but I can find zero evidence of the flag. Maybe you'll have better luck than me?
与えられたファイルがこちら。
# file zero.txt zero.txt: UTF-8 Unicode (with BOM) text, with very long lines, with no line terminators # cat zero.txt Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus quis tempus ante, nec vehicula mi. Aliquam nec nisi ut neque interdum auctor. Aliquam felis orci, vestibulum sit amet ante at, consectetur lobortis eros. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. In finibus magna mauris, quis auctor libero congue quis. Duis sagittis consequat urna non tristique. Pellentesque eu lorem id quam vestibulum ultricies vel ac purus.
一見普通のテキストファイルだが、「zero evidence」が含まれている?
全然ぜ全然分からず、色々ガンバって辿り着いたのがこれ。
Unicode ゼロ幅スペースを利用して情報を隠して仕込む - A painter and a black cat
そんなんあるんか!早速試してみる。
Unicode Steganography with Zero-Width Characters
すげーです。なぜかLinux環境で表示させたやつのコピペは上手くいかなかった。
flag: utflag{whyNOT@sc11_4927aajbqk14}
Locked KitKat - zer0ops CTF 2020 Forensics writeup
世間様は4月ですが、自分は3月を振り返っています。
2020/03/07 09:00 JST — 2020/03/09 09:00 JSTに行われた「zer0ops CTF 2020」の「Locked KitKat」のwriteupをお届け。
ctftime.org
色んな人が書いているので、見飽きているかもしれないけれど見ている方には感謝しかない。
Locked KitKat
We've extracted the internal disk from the Android device of the suspect. Can you find the pattern to unlock the device? Please submit the correct pattern here.
とりあえず与えられたファイルの情報収集。
# file evidence.tar.gz_1a9268f23f3fb6590d05f30901b7be7b.tar.gz evidence.tar.gz_1a9268f23f3fb6590d05f30901b7be7b.tar.gz: gzip compressed data, last modified: Thu Mar 5 01:11:34 2020, from Unix, original size modulo 2^32 536872960 # tar zxvf evidence.tar.gz_1a9268f23f3fb6590d05f30901b7be7b.tar.gz android.4.4.x86.img # file android.4.4.x86.img android.4.4.x86.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)
パターンロックを解くのが今回の目的で、androidのイメージが渡されたってことはパターンロックファイルを持って来ればいいのでしょう。
ということで 「android pattern lock」とかでおググります。
良さそうなのを発見する。
Can You Bypass the Android Lock Screen?
このサイトから、「/data/system/gesture.key」にパターンロックが記録されていることが分かる。
では、「android.4.4.x86.img」から「gesture.key」を取り出すために、The Sleuth Kitでの解析準備に入る。
# img_stat -t android.4.4.x86.img raw # mmls android.4.4.x86.img Cannot determine partition type
てっきりファイル名「android.4.4.x86.img」からandroidの全体イメージかと思っていたけど違うようだ。
全体のイメージであれば複数のパーティション領域が確認できるはず。どういうことかというと。
Partitions and Images | Android Open Source Project
Android partitions explained
Android デバイスのパーティション構成概要 | まくまくAndroidノート
[Android] Androidの内部構成について - 攻撃は最大の防御なり
これらのサイトにあるように、androidはlinuxでいうrootディレクトリにあるような重要ディレクトリがパーティション分けされているような作りになっている。なので、本来ディスク全体のイメージは例えば、次のようになっている。
# mmls this_is_it.img GUID Partition Table (EFI) Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 000: Meta 0000000000 0000000000 0000000001 Safety Table 001: ------- 0000000000 0000000255 0000000256 Unallocated 002: Meta 0000000001 0000000001 0000000001 GPT Header 003: Meta 0000000002 0000000012 0000000011 Partition Table 004: 000 0000000256 0000131327 0000131072 modem 005: 001 0000131328 0000132351 0000001024 sbl1 006: 002 0000132352 0000132415 0000000064 DDR 007: ------- 0000132416 0000132607 0000000192 Unallocated 008: 003 0000132608 0000134655 0000002048 aboot 009: ------- 0000134656 0000135607 0000000952 Unallocated 010: 004 0000135608 0000136107 0000000500 rpm 011: ------- 0000136108 0000136607 0000000500 Unallocated 012: 005 0000136608 0000137607 0000001000 tz 013: 006 0000137608 0000137863 0000000256 hyp 014: ------- 0000137864 0000138631 0000000768 Unallocated 015: 007 0000138632 0000139655 0000001024 utags 016: 008 0000139656 0000143751 0000004096 logs 017: ------- 0000143752 0000143871 0000000120 Unallocated 018: 009 0000143872 0000143903 0000000032 sec 019: ------- 0000143904 0000144127 0000000224 Unallocated 020: 010 0000144128 0000151175 0000007048 factorytune1 021: 011 0000151176 0000154623 0000003448 padA 022: 012 0000154624 0000155647 0000001024 metadata 023: 013 0000155648 0000157695 0000002048 abootBackup 024: ------- 0000157696 0000158647 0000000952 Unallocated 025: 014 0000158648 0000159147 0000000500 rpmBackup 026: ------- 0000159148 0000159647 0000000500 Unallocated 027: 015 0000159648 0000160647 0000001000 tzBackup 028: 016 0000160648 0000161671 0000001024 utagsBackup 029: 017 0000161672 0000161927 0000000256 hypBackup 030: ------- 0000161928 0000162695 0000000768 Unallocated 031: 018 0000162696 0000172031 0000009336 padB 032: 019 0000172032 0000173055 0000001024 frp 033: 020 0000173056 0000176127 0000003072 modemst1 034: 021 0000176128 0000179199 0000003072 modemst2 035: 022 0000179200 0000180175 0000000976 hob 036: 023 0000180176 0000180239 0000000064 dhob 037: ------- 0000180240 0000180479 0000000240 Unallocated 038: 024 0000180480 0000183551 0000003072 fsg 039: 025 0000183552 0000183553 0000000002 fsc 040: 026 0000183554 0000183569 0000000016 ssd 041: 027 0000183570 0000183825 0000000256 cid 042: 028 0000183826 0000192017 0000008192 logo 043: 029 0000192018 0000200209 0000008192 clogo 044: ------- 0000200210 0000200447 0000000238 Unallocated 045: 030 0000200448 0000216831 0000016384 persist 046: 031 0000216832 0000217855 0000001024 misc 047: 032 0000217856 0000283391 0000065536 boot 048: 033 0000283392 0000348895 0000065504 recovery 049: 034 0000348896 0000369487 0000020592 factorytune2 050: ------- 0000369488 0000369663 0000000176 Unallocated 051: 035 0000369664 0000386047 0000016384 kpan 052: 036 0000386048 0000393215 0000007168 padC 053: 037 0000393216 0000425983 0000032768 sp 054: 038 0000425984 0000458751 0000032768 keystore 055: 039 0000458752 0000491519 0000032768 oem 056: 040 0000491520 0000524287 0000032768 carrier 057: 041 0000524288 0004227071 0003702784 system 058: 042 0004227072 0004751359 0000524288 cache 059: 043 0004751360 0015204095 0010452736 userdata 060: ------- 0015204096 0015269887 0000065792 Unallocated
凄いごちゃごちゃしている。そんで多分ちょっと古い。
~閑話休題~
話を戻して、「gesture.key」が必要なのでおそらく今回与えられたイメージはユーザーデータを扱う「/data」パーティションのハズ。
# fsstat -t android.4.4.x86.img ext4 # fls -i raw -f ext4 android.4.4.x86.img d/d 11: lost+found d/d 12: app d/d 27: nativebenchmark d/d 29: nativetest d/d 8193: dontpanic d/d 16385: misc d/d 24577: local d/d 8194: data d/d 24579: app-private d/d 8195: app-asec d/d 24580: app-lib d/d 8196: property d/d 8197: ssh d/d 24581: dalvik-cache d/d 24582: resource-cache d/d 24583: drm d/d 8199: mediadrm l/l 36: bugreports d/d 24584: security d/d 8200: user d/d 24585: media d/d 8204: system d/d 16402: backup r/r 37: .layout_version V/V 32769: $OrphanFiles (別にfls android.4.4.x86.imgでも良いんですけどね)
思った通り、androidの「data」パーティションのようである。つまり、「/data/system/gesture.key」にあるということだったので「/system」下に目的ファイルがある。
# fls -i raw -f ext4 android.4.4.x86.img 8204 r/r 8207: batterystats.bin d/d 8206: procstats d/d 8205: ifw d/d 8210: users d/d 8208: usagestats r/r 8214: uiderrors.txt r/r 8385: packages.xml r/r 8361: packages.list r/r 8346: entropy.dat d/d 8354: sync d/d 8359: inputmethod r/r 8363: locksettings.db d/d 8362: netstats r/r 8364: locksettings.db-wal r/r 8365: locksettings.db-shm r/r 8366: framework_atlas.config r/r 8383: called_pre_boots.dat s/h 8384: ndebugsocket d/d 8414: dropbox r/r 8396: appops.xml d/d 8421: registered_services r/r 8495: gesture.key r/r 8497: device_policies.xml r/r * 8497(realloc): device_policies.xml.tmp # icat -i raw -f ext4 android.4.4.x86.img 8495 > gesture.key
「gesture.key」は取得した。ここから脳死でパターンロックを解読する場合、「android gesture key decode」等とおググりなさって出てきたプログラムを走らせれば良い。
脳死でパターンロック解読例
GitHub - sch3m4/androidpatternlock: A little Python tool to crack the Pattern Lock on Android devices
この「aplc.py」を使用。
# python aplc.py gesture.key ################################ # Android Pattern Lock Cracker # # v0.2 # # ---------------------------- # # Written by Chema Garcia # # http://safetybits.net # # chema@safetybits.net # # @sch3m4 # ################################ [i] Taken from: http://forensics.spreitzenbarth.de/2012/02/28/cracking-the-pattern-lock-on-android/ [:D] The pattern has been FOUND!!! => 321564 [+] Gesture: ----- ----- ----- | | | 3 | | 2 | ----- ----- ----- ----- ----- ----- | 1 | | 6 | | 4 | ----- ----- ----- ----- ----- ----- | 5 | | | | | ----- ----- ----- It took: 0.7533 seconds
今回の場合は用意されたwebページでパターンロックを入力すると、flagが貰えた。
flag: zer0pts{n0th1ng_1s_m0r3_pr4ct1c4l_th4n_brut3_f0rc1ng}
「gesture.key」をもう少し詳しく見たい場合
「gesture.key」には、パターンロック画面の3×3に左上から例えば1,2,3,,,,9のように番号づけして、パターンロック解除に必要な数字の順番(最小4桁、最大9桁)がソルト無しのSHA-1ハッシュで記録されているらしい(参考
Password storage in Android M)。
Android's pattern unlock is entered by joining at least four points on a 3×3 matrix (some custom ROMs allow a bigger matrix). Each point can be used only once (crossed points are disregarded) and the maximum number of points is nine. The pattern is internally converted to a byte sequence, with each point represented by its index, where 0 is top left and 8 is bottom right. Thus the pattern is similar to a PIN with a minimum of four and maximum of nine digits which uses only nine distinct digits (0 to 8). However, because points cannot be repeated, the number of variations in an unlock pattern is considerably lower compared to those of a nine-digit PIN. As pattern unlock is the original and initially sole unlock method supported by Android, a fair amount of research has been done about it's (in)security. It has been shown that patterns can be guessed quite reliably using the so called smudge attack, and that the total number of possible combinations is less than 400 thousand, with only 1624 combinations for 4-dot (the default) patterns.
なので、ハッシュとパターンの番号のリスト(AndroidGestureSHA1.txt)と比較すれば、簡単に分かってしまう。
# grep -i `xxd -p gesture.key ` AndroidGestureSHA1.txt 432675;03 02 01 05 06 04;179E58178A7C5195110E0A26D91C71926AF01349
よって脳死と同じ結果が得られた。
どういうことかというと、
----- ----- ----- | 1 | | 2 | | 3 | ----- ----- ----- ----- ----- ----- | 4 | | 5 | | 6 | ----- ----- ----- ----- ----- ----- | 7 | | 8 | | 9 | ----- ----- -----
例えばこのように番号付けして、パターンロック解除パターンをSHA1ハッシュしたものが「gesture.key」らしい。実際はこのようになっている。
# xxd gesture.key 00000000: 179e 5817 8a7c 5195 110e 0a26 d91c 7192 ..X..|Q....&..q. 00000010: 6af0 1349 j..I # cat AndroidGestureSHA1.txt | head ; Android OS gesture.key dictionary ; (c) Oxygen Software 2011 ; http://www.oxygen-forensic.com ; http://www.android-forensics.com Gesture;Pattern sequence;Pattern SHA-1; 1234;00 01 02 03;A02A05B025B928C039CF1AE7E8EE04E7C190C0DB 1235;00 01 02 04;6E36A9BFACF6C4637D64042B11CB78BFDDAF8BF3 1236;00 01 02 05;101B2A675E9FB9546336D5B9EF70418B594184F4 1237;00 01 02 06;30F26B9825EA6F2EF6DBF6A88959774314D83F65 1238;00 01 02 07;8C33B9D8BB8398DA8F19D9E946D589F32321B7BD
じゃあ、同じように最小4桁、最大9桁の数字をSHA1ハッシュすればパターンロックファイルが再現できるのかというと、そうでは無かった。なぜか同じハッシュを作ろうと思っても作れなかった。単純に数字の組み合わせのハッシュではなく、パターンの座標とかがハッシュされているのだろうか。
このハッシュファイルは一体何のSHA1ハッシュ!?
謎が謎を呼ぶ。
何か情報を持っている人がいれば教えてください。
Autopsy & The Sleuth Kitの基本的な使い方(2020/04/12更新)
autopsyとthe sleuth kitいえば、ディスクイメージの解析に使われるツールキットである。
この記事では、基本的なautopsyとthe sleuth kitの使い方を軽くさらっていく。
The Sleuth Kit (TSK) & Autopsy: Open Source Digital Forensics Tools
今回はイメージ解析検証のために「Digital Forensics Tool Testing Images」のうちのJPEG Search Test #8で配布されている「8-jpeg-search.dd」のイメージを利用する。
%注意%
あくまでCTFとかで気軽に使うレベルの簡単な使い方の話をしているので、実務レベルの基本設定ではないと思います。
Autopsy(GUI版,4.10.0)
起動には時間が掛かるが使い方が一番分かりやすいのは、やはりGUI版。主にwindowsではGUIでインストールする人が多いのでは。
GUI版ではautopsyを起動すると、始めにケースを選択する画面が開く。
これは、統合開発環境とかでいうプロジェクトを選択するような画面。とりあえず初めてなのでNew caseを選択してケースを作成。
特にこだわりがなければケース名を指定するだけで、付加情報は入力しなくても良いと思っている。
ケースが作成されればすぐにデータソースの追加が選択されるが、自分でデータソースを追加する場合は左上の「データソースの追加」を選択する。
今回はイメージファイルの解析なのでイメージファイルを選択して、次へ。
解析したいイメージファイルのパスを選択する。タイムゾーンは、状況に応じて変更する。
不必要な部分があれば、無駄にモジュールを読み込むことが無いのでイメージ読み込みの時間が減るはずだが、あまり気にせずデフォルトでやっている。
ここで、赤文字でエラーとか出なければデータソースの追加成功。エラーが出ていれば、エラーに応じて変更を加えるか、イメージ自体に問題があればそちらをどうにかしてください。
ここまで来ればもう簡単。「8-jpeg-search.dd」を選択すれば、Explorerのようにイメージファイルを探索できる。
任意のディレクトリやファイルを右クリックすることで、ファイル抽出が可能である。
また、おすすめは「Timeline」。
ファイルアクセスの記録とか色々可視化してくれる。
ケースの削除の仕方はよく分からないので、ケース作成時に作成されたフォルダごと消してます。
Autopsy(WebGUI版)
AutopsyはWevGUI版もあって、Linux環境でよく使われているイメージ?がある。
とりあえず自分はKali linux環境でやっている。
まずは、autopsyを起動すると,
root@kali:~# autopsy ============================================================================ Autopsy Forensic Browser http://www.sleuthkit.org/autopsy/ ver 2.24 ============================================================================ Evidence Locker: /var/lib/autopsy Start Time: Wed Apr 1 23:28:54 2020 Remote Host: localhost Local Port: 9999 Open an HTML browser on the remote host and paste this URL in it: http://localhost:9999/autopsy Keep this process running and use <ctrl-c> to exit
このように準備されるので、webブラウザで「http://localhost:9999/autopsy」にアクセスすると、こちらもケース選択から始まる。
初めなので、NEW CASEを選択して、Case Nameを入力。
ここでケースの作成は完了するが、ケースの中にhostを作成する必要がある。
Caseの中で、hostごとに作業スペースがあるらしい。
特に必要がなければ、デフォルトでいく。
ここまで、来るとやっと「ADD IMAGE」が選択できるので解析するイメージを選択する。
「ADD IMAGE FILE」を選択すれば、イメージ選択画面に移る。Locationには絶対パスでファイルを指定する。ファイルの絶対パスの取得はLinux環境では、find `pwd` -name "[filename]"
がおススメ。例えば今回の場合。
# ls 8-jpeg-search.dd COPYING-GNU.txt README.txt index.html results.txt # find `pwd` -name "8-jpeg-search.dd" /root/DFIR/test/8-jpeg-search/8-jpeg-search.dd
このようにパス取得した。
イメージ選択画面では、イメージファイルのタイプとして「Disk」か「Partition」を選択できる。この判断は、解析対象がディスク全体のイメージならば「Disk」、パーティションやddイメージであれば「Partition」を選択。最後のImport Methodは基本的にcopyを選んでおけば良いと思っている。
特に必要なければ「Ignore」で、「File Sytem」に関して問題が無さそうならばそのまま。
イメージの追加に成功したならば、いざ「ANALYZE」!
遷移後の画面で、「FILE ANALYSIS」を選択するとGUI版と同じような画面を拝める。あとは、ディレクトリを選択すれば中に入れるし、ファイルを選択すればファイルの情報を見れえる。正直なところ、WebGUIはあまり使ったことがないのでこれ以上深い話はしない。
The Sleuth Kit
The Sleuth KitはAutopsyのコマンドラインツールキットである。
このブログでもちょっと扱ったことある。もしかしたら今回よりも詳しいこと書いているかもしれない。
The Sleuth Kitの使い方に触れながら Determine Window Version! - 4ensiX
「The Sleuth Kit」と調べると、とりあえずfls
使ってイメージの中を探索して、icat
でファイルを取り出すと書いてあるけど、それだけじゃ開けないイメージだってある。
パーティションだけのイメージファイルならば、fls [image_file]
で事足りるかもしれないが、ディスク全体のイメージファイルが渡された場合、ファイルタイプやファイルシステム、パーティションのアドレスを渡さなければ解析ができない。
結論から言うと今回の「8-jpeg-search.dd」の場合はパーティションなのでfls [image_file]
でいけるが丁寧にやっていく。
1. イメージファイルのタイプを判定
img_stat image_file
を利用。今回の場合は、
# img_stat -t 8-jpeg-search.dd raw
欲しい情報のみに絞るために-tオプションを利用。
2. パーティションを確認
mmls image_file
を利用する。解析対象が、パーティションであれば必要ない。よって今回のケースでは行う必要はないがmmls
を走らせてみると、
# mmls 8-jpeg-search.dd Cannot determine partition type
ディスク全体のイメージファイルに対して行った場合には、例としてThe Sleuth Kitの使い方に触れながら Determine Window Version! - 4ensiXで扱ったwindows10を見ると
#mmls win10simple.raw 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 0001187839 0001185792 NTFS / exFAT (0x07) 003: 000:001 0001187840 0025163775 0023975936 NTFS / exFAT (0x07) 004: ------- 0025163776 0025165823 0000002048 Unallocated
ディスク全体のイメージファイルであれば、fls
使用時にパーティション領域の始まりを指定する必要があるので、この確認は重要となる。
今のところの経験だと、Linuxと古いwindwos(XP以前?)は一つ目のパーティション領域、新しいwindowsは二つ目のパーティション領域(上記の「003: 000:001 0001187840 0025163775 0023975936 NTFS / exFAT (0x07)
」)を見ることが多いと思われる。
androidは、linuxのルートディレクトリ内のディレクトリがパーティションされているような作りになっている。
3. ファイルシステムを確認
fsstat -i file_type [-o partition_start] -t image_file
を利用する。今回の場合は
# fsstat -i raw -t 8-jpeg-search.dd ntfs
欲しい情報のみに絞るために-tオプションを利用した。
4. イメージの解析を開始
ここまで来れば、イメージの解析を始められるのでfls -i file_type -f file_system [-o partition_start] image_file [inode number]
を利用する。また、i-node番号を付けることで、ディレクトリの中身を確認できる。今回の場合。
# fls -i raw -f ntfs 8-jpeg-search.dd r/r 4-128-4: $AttrDef r/r 8-128-2: $BadClus r/r 8-128-1: $BadClus:$Bad r/r 6-128-1: $Bitmap r/r 7-128-1: $Boot d/d 11-144-4: $Extend r/r 2-128-1: $LogFile r/r 0-128-1: $MFT r/r 1-128-1: $MFTMirr r/r 9-128-8: $Secure:$SDS r/r 9-144-11: $Secure:$SDH r/r 9-144-5: $Secure:$SII r/r 10-128-1: $UpCase r/r 3-128-3: $Volume d/d 27-144-1: alloc d/d 37-144-1: archive d/d 30-144-1: del1 d/d 47-144-1: del2 d/d 33-144-1: invalid d/d 41-144-1: misc d/d 48-144-1: RECYCLER d/d 45-144-1: System Volume Information V/V 52: $OrphanFiles # fls -i raw -f ntfs 8-jpeg-search.dd 27-144-1 (イメージ的にはcd alloc/ をしたような感じ) r/r 29-128-3: file1.jpg r/r 28-128-3: file2.dat
このように、探索できる。ここには、ファイルタイプ、i-node番号、ファイル名が出力されている。
5. ファイルの抽出
icat -i file_type -f file_system [-o partition_start] image_file] inode_number > file
と、イメージ内のファイルを任意のファイル名で取得する。上記で発見した「file1.jpg」を抽出する場合には以下のように、fls
コマンドで確認したi-node番号「29-128-3」を指定してicatを利用する。
# icat -i raw -f ntfs 8-jpeg-search.dd 29-128-3 > file1.jpg # file file1.jpg file1.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 698x752, components 3
6. ディレクトリ/フォルダの抽出
tsk_recover [-a/-e] -i file_type -f file_system [-o partition_start] -d directory_inode number image_file output_directory
で取り出せる。ここで、tsk_recover
はデフォルトだと未割当のファイル(削除済み等)しか対象になっていない。オプションを付けて適宜、割り当て状態ファイル(-a)、未割当割り当て含む(-e)を対象として利用する。「alloc」ディレクトリを抽出する場合には、「alloc」のi-node番号を指定して以下のように利用する。
# fls -i raw -f ntfs 8-jpeg-search.dd (snip) d/d 27-144-1: alloc (snip) # fls -i raw -f ntfs 8-jpeg-search.dd 27-144-1 r/r 29-128-3: file1.jpg r/r 28-128-3: file2.dat # cd alloc/ ~/alloc# ls file1.jpg file2.dat
ついでに、タイムラインのようなものの取得は
ここにあるようにできる。今回の場合は
# fls -m " " -r 8-jpeg-search.dd > body2.txt # cat body2.txt (snip) 0|C:/alloc ($FILE_NAME)|27-48-4|d/drwxrwxrwx|0|0|76|1086838026|1086838026|1086838026|1086838026 0|C:/alloc|27-144-1|d/drwxrwxrwx|0|0|256|1086838056|1086838056|1086838056|1086838026 0|C:/alloc/file1.jpg ($FILE_NAME)|29-48-2|r/rrwxrwxrwx|0|0|84|1086838056|1086838056|1086838056|1086838056 0|C:/alloc/file1.jpg|29-128-3|r/rrwxrwxrwx|0|0|274260|1086838056|1086850780|1086838056|1086838056 0|C:/alloc/file2.dat ($FILE_NAME)|28-48-2|r/rrwxrwxrwx|0|0|84|1086838056|1086838056|1086838056|1086838056 0|C:/alloc/file2.dat|28-128-3|r/rrwxrwxrwx|0|0|26081|1086838056|1086850012|1086838056|1086838056 0|C:/archive ($FILE_NAME)|37-48-4|d/drwxrwxrwx|0|0|80|1086838117|1086838117|1086838117|1086838117 0|C:/archive|37-144-1|d/drwxrwxrwx|0|0|472|1086838132|1086838131|1086838131|1086838117 0|C:/archive/file10.tar.gz ($FILE_NAME)|38-48-2|r/rrwxrwxrwx|0|0|92|1086838130|1086838130|1086838130|1086838130 0|C:/archive/file10.tar.gz|38-128-4|r/rrwxrwxrwx|0|0|207272|1086838131|1086851934|1086838131|1086838130 0|C:/archive/file8.zip ($FILE_NAME)|39-48-2|r/rrwxrwxrwx|0|0|84|1086838131|1086838131|1086838131|1086838131 0|C:/archive/file8.zip|39-128-3|r/rrwxrwxrwx|0|0|335371|1086838131|1086851802|1086838131|1086838131 0|C:/archive/file9.boo ($FILE_NAME)|40-48-2|r/rrwxrwxrwx|0|0|84|1086838131|1086838131|1086838131|1086838131 0|C:/archive/file9.boo|40-128-3|r/rrwxrwxrwx|0|0|294124|1086838134|1086851866|1086838134|1086838131 0|C:/del1 ($FILE_NAME)|30-48-5|d/drwxrwxrwx|0|0|74|1086838080|1086838080|1086838080|1086838064 0|C:/del1|30-144-1|d/drwxrwxrwx|0|0|48|1086839955|1086839955|1086839955|1086838064 0|C:/del1/file6.jpg ($FILE_NAME) (deleted)|32-48-2|-/rrwxrwxrwx|0|0|84|1086838080|1086838080|1086838080|1086838080 0|C:/del1/file6.jpg (deleted)|32-128-3|-/rrwxrwxrwx|0|0|175630|1086838080|1086850088|1086838080|1086838080 0|C:/del2 ($FILE_NAME)|47-48-4|d/drwxrwxrwx|0|0|74|1086838999|1086838999|1086838999|1086838999 0|C:/del2|47-144-1|d/drwxrwxrwx|0|0|48|1086839963|1086839963|1086839963|1086838999 0|C:/del2/file7.hmm ($FILE_NAME) (deleted)|31-48-4|-/rrwxrwxrwx|0|0|84|1086838080|1086850158|1086838080|1086838080 0|C:/del2/file7.hmm (deleted)|31-128-3|-/rrwxrwxrwx|0|0|326859|1086839018|1086850158|1086839024|1086838080 0|C:/invalid ($FILE_NAME)|33-48-4|d/drwxrwxrwx|0|0|80|1086838088|1086838088|1086838088|1086838088 0|C:/invalid|33-144-1|d/drwxrwxrwx|0|0|360|1086838101|1086838100|1086838100|1086838088 0|C:/invalid/file3.jpg ($FILE_NAME)|35-48-2|r/rrwxrwxrwx|0|0|84|1086838100|1086838100|1086838100|1086838100 0|C:/invalid/file3.jpg|35-128-3|r/rrwxrwxrwx|0|0|214228|1086838100|1086852422|1086838100|1086838100 0|C:/invalid/file4.jpg ($FILE_NAME)|36-48-2|r/rrwxrwxrwx|0|0|84|1086838100|1086838100|1086838100|1086838100 0|C:/invalid/file4.jpg|36-128-3|r/rrwxrwxrwx|0|0|189021|1086838102|1086853086|1086838102|1086838100 0|C:/invalid/file5.rtf ($FILE_NAME)|34-48-2|r/rrwxrwxrwx|0|0|84|1086838100|1086838100|1086838100|1086838100 0|C:/invalid/file5.rtf|34-128-3|r/rrwxrwxrwx|0|0|148102|1086838100|1086853314|1086838100|1086838100 0|C:/misc ($FILE_NAME)|41-48-4|d/drwxrwxrwx|0|0|74|1086838140|1086838140|1086838140|1086838140 0|C:/misc|41-144-1|d/drwxrwxrwx|0|0|360|1086838158|1086838158|1086838158|1086838140 0|C:/misc/file11.dat ($FILE_NAME)|42-48-2|r/rrwxrwxrwx|0|0|86|1086838157|1086838157|1086838157|1086838157 0|C:/misc/file11.dat|42-128-3|r/rrwxrwxrwx|0|0|272753|1086838157|1086853486|1086838157|1086838157 0|C:/misc/file12.doc ($FILE_NAME)|43-48-2|r/rrwxrwxrwx|0|0|86|1086838157|1086838157|1086838157|1086838157 0|C:/misc/file12.doc|43-128-3|r/rrwxrwxrwx|0|0|131584|1086838158|1086852058|1086838158|1086838157 0|C:/misc/file13.dll ($FILE_NAME)|44-48-2|r/rrwxrwxrwx|0|0|86|1086838158|1086838158|1086838158|1086838158 0|C:/misc/file13.dll|44-128-3|r/rrwxrwxrwx|0|0|58391|1086838185|1086838185|1086838185|1086838158 0|C:/misc/file13.dll:here|44-128-5|r/rrwxrwxrwx|0|0|124038|1086838185|1086838185|1086838185|1086838158 0|C:/RECYCLER ($FILE_NAME)|48-48-2|d/dr-xr-xr-x|0|0|82|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER|48-144-1|d/dr-xr-xr-x|0|0|328|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003 ($FILE_NAME)|49-48-2|d/dr-xr-xr-x|0|0|156|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003|49-144-1|d/dr-xr-xr-x|0|0|248|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/desktop.ini ($FILE_NAME)|50-48-2|r/rr-xr-xr-x|0|0|88|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/desktop.ini|50-128-1|r/rr-xr-xr-x|0|0|65|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/INFO2 ($FILE_NAME)|51-48-2|r/rr-xr-xr-x|0|0|76|1086839950|1086839950|1086839950|1086839950 0|C:/RECYCLER/S-1-5-21-1757981266-484763869-1060284298-1003/INFO2|51-128-1|r/rr-xr-xr-x|0|0|20|1086839971|1086839971|1086839971|1086839950 0|C:/System Volume Information ($FILE_NAME)|45-48-2|d/dr-xr-xr-x|0|0|116|1086838858|1086838858|1086838858|1086838858 0|C:/System Volume Information|45-144-1|d/dr-xr-xr-x|0|0|160|1086839893|1086838858|1086838858|1086838858 0|C:/System Volume Information/tracking.log ($FILE_NAME)|46-48-5|r/rr-xr-xr-x|0|0|90|1086838858|1086838858|1086838858|1086838858 0|C:/System Volume Information/tracking.log|46-128-4|r/rr-xr-xr-x|0|0|20480|1086839077|1086839077|1086839077|1086838858 0|C:/$OrphanFiles|52|V/V---------|0|0|0|0|0|0|0
こんな感じで取得した。
The Sleuth Kitに関しては、ここら辺も見て頂きたい。
とりあえず以上!!!!!
NeverLAN CTF 2020 PCAP/Forensic writeup
今回は、2020/02/09 00:00 JST — 2020/02/12 08:00 JSTに行われた NeverLAN CTF 2020のPCAPとForensicジャンルのwriteupをお届けする。
とてもとっつき易く基本を学べるので、何も分からない状態で初めても大丈夫そうなCTF。今言っても意味ないけれど、オンラインCTFの入門としてとてもおススメ。
PCAP
このジャンルの問題は全て、writeupを書くほどのものか怪しいレベルの簡単さであったのでほんの少し触れるだけ。
FTP
FTPのパケットキャプチャファイルが与えられる。FTPはデフォルトで暗号化されていないので丸見えというお話。ストリームを眺めていればflag{*}が見える。
flag: flag{sftp_OR_ftps_not_ftp}
Teletype Network
問題のまんまtelnetのパケットキャプチャファイルが与えれる。こちらもデフォルトでは暗号化されていないので通信が見える。
flag: flag{telnet_1s_n0t_secur3}
Unsecured Login
httpの通信でログインしているので通信みえちゃうというお話。ストリームを眺めているとpassword入力にflagがある。
flag: flag{n0httpsn0l0gin}
Unsecured Login2
ちゃんとパケットの中身を見ていないので「Unsecured Login」と違いが分からなかった。同じようなところにflagがある。
flag: flag{ensure_https_is_always_used}
PCAPジャンルはパケットキャプチャファイルにstrings | grep でflag取れた。
Forensic
Forensicのキソのキソを学べる問題。
Listen to this
You hear that?
*Your flag will be in the normal flag{flagGoesHere] syntax
-ps This guy might be important
-ZestyFE
まず「HiddenAudio.mp3」が与えられる。このファイルは音声ファイルであり、「HiddenAuidio」という名であるからには何か音声が隠されているのだろうという推測でaudacityで開く。ただ波形をよく見ても分からなかったので、ctfでありがちな音声のスペクトログラム表示してみる。スペクトログラムを表示して一番初めのあたりを拡大してみると何か見える。
何かモールス信号ぽい気がするので、変換サイトで見てみる。
「FLA」とくれば、次は「G」となりそうな気がする。方向性は良さそうだが見づらいので、スペクトログラムを弄りたい。
波形を眺めたり、音を聞いているとボーカルを除去すればもう少し見やすくなる気がしてきた。
[エフェクト]->[Plug-in]->[ボーカルの低減と分離]を選択。そのまま「OK」を選択してみる。
凄い見やすくなったのでこれを変換にかける。変換してみると、flag{*}を何度も繰り返していることが分かる。
flag: flag{ditsanddahsforlife}
[メモ]もしかして、mp3はbinwalkに引っかからない?
Look into the past
We've captured a snapshot of a computer, but it seems the user was able to encrypt a file before we got to it. Can you figure out what they encrypted?
Your flag will be in the normal flag{flagGoesHere} syntax.
-N30
与えられた.tar.gzのファイルを解凍する。
$ ls look_into_the_past/ bin boot dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var
マシンのルートディレクトリぽい。問題文から/home/Userに何かありそうな気がする。
$ ls * Desktop: Documents: flag.txt.enc libssl-flag.txt.enc Downloads: Music: Pictures: doggo.jpeg Public: Videos:
/home/User以下のディレクトリをみてみると、明らかに怪しい「flag.txt.enc」というファイルがある。.encとなっているということは暗号化されていそうな気がする。
$ file Documents/* # /home/User Documents/flag.txt.enc: openssl enc'd data with salted password Documents/libssl-flag.txt.enc: openssl enc'd data with salted password
やはりこのファイルは暗号化されている。opensslを使って復号するには、パスワードが必要になる。一瞬パスワードクラックを考えたが、このパスワードはどこかに在りそうな気がした。なぜならこの問題は「Look into the past」である。過去を見る。また、今回のような暗号化はコマンドラインで行われることが多い。よって「.bash_history」に何か手がかりがありそうな気がする。
$ ls -al 合計 52 drwxr-xr-x 9 1000 1000 4096 2月 9 01:24 . drwxr-xr-x 3 1000 1000 4096 2月 9 01:24 .. -rw-r--r-- 1 1000 1000 349 2月 7 03:33 .bash_history -rw-r--r-- 1 1000 1000 864 2月 7 03:34 .bashrc -rw-r--r-- 1 1000 1000 672 2月 7 03:34 .profile -rw-r--r-- 1 1000 1000 37 2月 7 03:33 .vimrc drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Desktop drwxr-xr-x 2 1000 1000 4096 2月 9 01:52 Documents drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Downloads drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Music drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Pictures drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Public drwxr-xr-x 2 1000 1000 4096 2月 9 01:24 Videos $ cat .bash_history cd Documents openssl enc -aes-256-cbc -salt -in flag.txt -out flag.txt.enc -k $(cat $pass1)$pass2$pass3 steghide embed -cf doggo.jpeg -ef $pass1 mv doggo.jpeg ~/Pictures useradd -p '$pass2' user sqlite3 /opt/table.db "INSERT INTO passwords values ('1', $pass3)" tar -zcf /opt/table.db.tar.gz /opt/table.db rm $pass1 unset $pass2 unset $pass3 exit
「.bash_history」に暗号化時のコマンドがしっかり残っていた。これに従って復号化すればいいのだが、パスワードは複数の場所に散りばめられているようである。なので一ずつ見つけていく。
まずは、「doggo.jpeg」に隠された「$pass1」から見ていく。「steghide」は画像ファイルにテキストなどを埋め込むステガノグラフィツールである。おそらく、「doggo.jpeg」さえあれば「$pass1」は見つけられる。
$ steghide extract -sf doggo.jpeg -xf pass1.txt $ cat pass1.txt JXrTLzijLb
展開時にパスワード入力が求められるが、パスワードは不要であった。
次に、追加したuserのパスワードが「$pass2」であるようなので、「/etc/shadow」をチェックする。
$ cat ../../etc/shadow # from /home/User (snip) user:KI6VWx09JJ:18011:0:99999:7:::
最後に、SQLiteのデータベースに「$pass3」が入っているようなので、「/opt/table.tar.gz」を解凍して「table.db」を「DB browser for SQLite」で確認する。 以上で、「flag.txt.enc」を復号するためのパスワードが揃った。
$ openssl enc -d -aes-256-cbc -salt -k JXrTLzijLbKI6VWx09JJnBNfDKbP5n -in Documents/flag.txt.enc -out flag.txt *** WARNING : deprecated key derivation used. Using -iter or -pbkdf2 would be better. $ cat flag.txt flag{h1st0ry_1n_th3_m4k1ng}
flag: flag{h1st0ry_1n_th3_m4k1ng}
Open Backpack
There's more to this picture
Your flag will be in the normal flag{flagGoesHere} syntax.
-NullB0n3s
まず次のようなファイル「openbackpack.jpg」が与えられる。 ここで、ファイル名や問題から「openbackpack.jpg」に他のファイルが含まれているような気がするのでbinwalkでチェックする。
$ binwalk openbackpack.jpg DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 JPEG image data, JFIF standard 1.01 30 0x1E TIFF image data, little-endian offset of first image directory: 8 328 0x148 JPEG image data, JFIF standard 1.01 9703 0x25E7 Copyright string: "CopyrightOwner> <rdf:Seq/> </plus:CopyrightOwner> <plus:Licensor> <rdf:Seq/> </plus:Licensor> </rdf:Description> </rdf:RDF> </x:" 9737 0x2609 Copyright string: "CopyrightOwner> <plus:Licensor> <rdf:Seq/> </plus:Licensor> </rdf:Description> </rdf:RDF> </x:xmpmeta> " 139267 0x22003 Zip archive data, at least v2.0 to extract, compressed size: 15928, uncompressed size: 695647, name: flag.png 155339 0x25ECB End of Zip archive, footer length: 22
思った通りいくつかファイルが含まれおり、それらのファイルの一つに「flag.png」を含むzipファイルを確認した。ここからファイルをカービングするのは、このままbinwalkでも、foremostでも宗教上の理由とかで色々あると思う。自分はddで。
$ dd if=openbackpack.jpg bs=1 skip=139267 of=output.zip 16094+0 レコード入力 16094+0 レコード出力 16094 bytes (16 kB, 16 KiB) copied, 0.0448263 s, 359 kB/s $ unzip output.zip Archive: output.zip inflating: flag.png
flag: flag{AlWaYs_cH3cK_y0ur_sTuFF}