4ensiX

4ensiX

FPと言ったものはFPを選んだが表示はTPになっていることに気づいた。

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

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に再生した音声を聞かせて解いた。音が再生されると自動で録音してくれるが、雑音の少ないところでやりましょう。

f:id:Zarat:20200406171249p:plain
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で開く。 f:id:Zarat:20200406173114p:plain メニューを開いて、スペクトログラムに切り替えると。 f:id:Zarat:20200406173339p:plain 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」派。

f:id:Zarat:20200406175824p:plain
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

f:id:Zarat:20200406181527p:plain
なんじゃそりゃ
flag: utflag{3lit3_h4ck3r}

最近はこんなものもあるらしい

GitHub - sherlly/PCRT: PCRT (PNG Check & Repair Tool), a tool to help check and fix the error in a PNG image.

# 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発見。 f:id:Zarat:20200406183651p:plain 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」が含まれている?
全然ぜ全然分からず、色々ガンバって辿り着いたのがこれ。

www.330k.info

Unicode ゼロ幅スペースを利用して情報を隠して仕込む - A painter and a black cat

そんなんあるんか!早速試してみる。

Unicode Steganography with Zero-Width Characters
f:id:Zarat:20200406192138p:plain すげーです。なぜか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の内部構成について - 攻撃は最大の防御なり
これらのサイトにあるように、androidlinuxでいう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を起動すると、始めにケースを選択する画面が開く。

f:id:Zarat:20200402111655p:plain
case選択
これは、統合開発環境とかでいうプロジェクトを選択するような画面。とりあえず初めてなのでNew caseを選択してケースを作成。 f:id:Zarat:20200402112307p:plain 特にこだわりがなければケース名を指定するだけで、付加情報は入力しなくても良いと思っている。
ケースが作成されればすぐにデータソースの追加が選択されるが、自分でデータソースを追加する場合は左上の「データソースの追加」を選択する。 f:id:Zarat:20200402113238p:plain 今回はイメージファイルの解析なのでイメージファイルを選択して、次へ。
f:id:Zarat:20200402113627p:plain 解析したいイメージファイルのパスを選択する。タイムゾーンは、状況に応じて変更する。
f:id:Zarat:20200402113820p:plain 不必要な部分があれば、無駄にモジュールを読み込むことが無いのでイメージ読み込みの時間が減るはずだが、あまり気にせずデフォルトでやっている。 f:id:Zarat:20200402114026p:plain ここで、赤文字エラーとか出なければデータソースの追加成功。エラーが出ていれば、エラーに応じて変更を加えるか、イメージ自体に問題があればそちらをどうにかしてください。
f:id:Zarat:20200402114429p:plain ここまで来ればもう簡単。「8-jpeg-search.dd」を選択すれば、Explorerのようにイメージファイルを探索できる。
f:id:Zarat:20200402115205p:plain 任意のディレクトリやファイルを右クリックすることで、ファイル抽出が可能である。
また、おすすめは「Timeline」。
f:id:Zarat:20200402115419p:plain
タイムライン
ファイルアクセスの記録とか色々可視化してくれる。
ケースの削除の仕方はよく分からないので、ケース作成時に作成されたフォルダごと消してます。

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」にアクセスすると、こちらもケース選択から始まる。

f:id:Zarat:20200402123209p:plain
webGUIのケース選択
初めなので、NEW CASEを選択して、Case Nameを入力。 f:id:Zarat:20200402123437p:plain ここでケースの作成は完了するが、ケースの中にhostを作成する必要がある。 Caseの中で、hostごとに作業スペースがあるらしい。 f:id:Zarat:20200402200808p:plain 特に必要がなければ、デフォルトでいく。
ここまで、来るとやっと「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

このようにパス取得した。 f:id:Zarat:20200402201120p:plain f:id:Zarat:20200402201649p:plain イメージ選択画面では、イメージファイルのタイプとして「Disk」か「Partition」を選択できる。この判断は、解析対象がディスク全体のイメージならば「Disk」、パーティションやddイメージであれば「Partition」を選択。最後のImport Methodは基本的にcopyを選んでおけば良いと思っている。 f:id:Zarat:20200403013045p:plain 特に必要なければ「Ignore」で、「File Sytem」に関して問題が無さそうならばそのまま。 f:id:Zarat:20200403181758p:plain イメージの追加に成功したならば、いざ「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に関しては、ここら辺も見て頂きたい。

The Sleuth Kit: Documents

The Sleuth Kit | Forensicist




とりあえず以上!!!!!

NeverLAN CTF 2020 PCAP/Forensic writeup

今回は、2020/02/09 00:00 JST — 2020/02/12 08:00 JSTに行われた NeverLAN CTF 2020のPCAPとForensicジャンルのwriteupをお届けする。

ctftime.org

とてもとっつき易く基本を学べるので、何も分からない状態で初めても大丈夫そうな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でありがちな音声のスペクトログラム表示してみる。スペクトログラムを表示して一番初めのあたりを拡大してみると何か見える。

f:id:Zarat:20200304231451p:plain
スペクトログラム表示の始めを拡大
何かモールス信号ぽい気がするので、変換サイトで見てみる。
f:id:Zarat:20200304231609p:plain
モールス信号ぽいやつを変換してみた
「FLA」とくれば、次は「G」となりそうな気がする。方向性は良さそうだが見づらいので、スペクトログラムを弄りたい。
波形を眺めたり、音を聞いているとボーカルを除去すればもう少し見やすくなる気がしてきた。
[エフェクト]->[Plug-in]->[ボーカルの低減と分離]を選択。そのまま「OK」を選択してみる。f:id:Zarat:20200304232002p:plain 凄い見やすくなったのでこれを変換にかける。変換してみると、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」で確認する。

f:id:Zarat:20200304234220p:plain
「DB browser for SQLite」で「table.db」を確認
以上で、「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」が与えられる。

f:id:Zarat:20200207104745j:plain
Open Backpackで与えられたファイル
ここで、ファイル名や問題から「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  

f:id:Zarat:20200304235242p:plain
flag.png
flag: flag{AlWaYs_cH3cK_y0ur_sTuFF}

色々キソを見直せるCTFだった

Find My Pass - HackTM CTF 2020 Forensic writeup

引き続きHackTM2020 Forensics Writeupをお届け。
前回記事 zarat.hatenablog.com

Find My Pass

問題文

I managed to forget my password for my KeePass Database but luckily I had it still open and managed to get a dump of the system's memory. Can you please help me recover my password?

Author: Legacy

https://mega.nz/#!IdUVwY6I!uJWGZ932xab44H4EJ-zVAqu6_UWNJcCVA4_PPXdqCyc
https://drive.google.com/open?id=1hUlGqJZYgbWaEu7w0JnPMqgYdFr8qVJe
password: eD99mLkU

リンクがいつまで生きているか分からない。
まず、与えられたファイル「HackTM.zip」でzipファイルだと思うので解凍する。

$ unzip HackTM.zip
Archive:  HackTM.zip
   skipping: HackTM.vmem             need PK compat. v5.1 (can do v4.6)

何故か解凍できなかった。zipファイルのフォーマット確認して直すところから始まるのかぁと思ったが、調べてみるとzipのフォーマットにバージョンがあって、unzipでサポート外のバージョンもあるらしい。

unzip で "need PK compat. v5.1 (can do v4.5)" と言われて解凍できない件 - CUBE SUGAR CONTAINER

ならば7zipを使えばいい。

$ 7za x HackTM.zip

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, 374180992 bytes (357 MiB)

Extracting archive: HackTM.zip
--
Path = HackTM.zip
Type = zip
Physical Size = 374180992


Enter password (will not be echoed):
Everything is Ok

Size:       2147483648
Compressed: 374180992

解凍して出てきたのはメモリダンプファイルなので、volatilityで解析していく。

$ volatility -f HackTM.vmem imageinfo
Volatility Foundation Volatility Framework 2.6
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86_24000, Win7SP1x86
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (/root/CTF/HackTMCTF2020/Find_Mypassword/writeup/HackTM.vmem)
                      PAE type : PAE
                           DTB : 0x185000L
                          KDBG : 0x82b7cb78L
          Number of Processors : 2
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0x80b96000L
                KPCR for CPU 1 : 0x807ca000L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2019-11-11 20:50:09 UTC+0000
     Image local date and time : 2019-11-11 12:50:09 -0800

とりあえず、pstreeを見る。

$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem pstree
Volatility Foundation Volatility Framework 2.6
Name                                                  Pid   PPid   Thds   Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
 0x85fff1e0:wininit.exe                               432    360      7     92 2019-11-11 20:49:22 UTC+0000
. 0x86513a70:lsm.exe                                  512    432     12    166 2019-11-11 20:49:22 UTC+0000
. 0x86438c00:services.exe                             484    432     25    270 2019-11-11 20:49:22 UTC+0000
.. 0x864e8030:dllhost.exe                            1820    484     21    205 2019-11-11 20:49:26 UTC+0000
.. 0x8670f030:svchost.exe                             876    484     36    587 2019-11-11 20:49:23 UTC+0000
... 0x86b3ad20:dwm.exe                               1956    876      5     77 2019-11-11 20:49:25 UTC+0000
.. 0x86abf1a0:vmtoolsd.exe                           1676    484     11    199 2019-11-11 20:49:25 UTC+0000
... 0x86a8f030:cmd.exe                               3372   1676      0 ------ 2019-11-11 20:50:09 UTC+0000
.... 0x86611870:ipconfig.exe                         3472   3372      0 ------ 2019-11-11 20:50:09 UTC+0000
.. 0x86606030:svchost.exe                             664    484     16    379 2019-11-11 20:49:23 UTC+0000
... 0x86dccc08:WmiPrvSE.exe                          3228    664     14    330 2019-11-11 20:49:34 UTC+0000
... 0x85ee9a38:WmiPrvSE.exe                          1748    664      9    145 2019-11-11 20:49:26 UTC+0000
... 0x85861678:mobsync.exe                           2260    664      8    163 2019-11-11 20:49:55 UTC+0000
.. 0x86bc6978:svchost.exe                             388    484      7     97 2019-11-11 20:49:26 UTC+0000
.. 0x86a4ed20:VGAuthService.                         1600    484      4     87 2019-11-11 20:49:25 UTC+0000
.. 0x8673ea38:svchost.exe                             928    484     34    804 2019-11-11 20:49:23 UTC+0000
.. 0x867b1aa0:svchost.exe                            1064    484      7    124 2019-11-11 20:49:23 UTC+0000
.. 0x869f87d8:spoolsv.exe                            1308    484     16    300 2019-11-11 20:49:24 UTC+0000
.. 0x866d5d20:svchost.exe                             812    484     27    577 2019-11-11 20:49:23 UTC+0000
... 0x86763d20:audiodg.exe                           1024    812      6    133 2019-11-11 20:49:23 UTC+0000
.. 0x86c47030:msdtc.exe                              2292    484     15    160 2019-11-11 20:49:27 UTC+0000
.. 0x86a58360:svchost.exe                            1468    484     34    352 2019-11-11 20:49:24 UTC+0000
.. 0x86a0cac0:svchost.exe                            1344    484     24    338 2019-11-11 20:49:24 UTC+0000
.. 0x86869030:svchost.exe                            1184    484     23    437 2019-11-11 20:49:23 UTC+0000
.. 0x8672f7f8:svchost.exe                             968    484     50    860 2019-11-11 20:49:23 UTC+0000
.. 0x86caf6f8:SearchIndexer.                         2636    484     14    612 2019-11-11 20:49:32 UTC+0000
... 0x86d1fd20:SearchProtocol                        2904   2636      7    265 2019-11-11 20:49:33 UTC+0000
... 0x86d4d030:SearchFilterHo                        2928   2636      5     89 2019-11-11 20:49:33 UTC+0000
.. 0x86c77030:VSSVC.exe                              2428    484      7    125 2019-11-11 20:49:27 UTC+0000
.. 0x86da3030:svchost.exe                            3076    484     11    360 2019-11-11 20:49:33 UTC+0000
.. 0x86a8cc38:taskhost.exe                           1580    484     11    223 2019-11-11 20:49:25 UTC+0000
.. 0x860e3030:dllhost.exe                            2108    484     18    216 2019-11-11 20:49:26 UTC+0000
.. 0x86661ad0:svchost.exe                             748    484     12    337 2019-11-11 20:49:23 UTC+0000
.. 0x86cf7030:wmpnetwk.exe                           2728    484     20    473 2019-11-11 20:49:32 UTC+0000
.. 0x86e844f0:WmiApSrv.exe                           3716    484      7    122 2019-11-11 20:49:47 UTC+0000
. 0x864b4d20:lsass.exe                                504    432     12    811 2019-11-11 20:49:22 UTC+0000
 0x863c5d20:csrss.exe                                 380    360      9    632 2019-11-11 20:49:22 UTC+0000
. 0x86ec7588:conhost.exe                             2520    380      0     30 2019-11-11 20:50:09 UTC+0000
 0x84a41800:System                                      4      0     97    410 2019-11-11 20:49:19 UTC+0000
. 0x8625aa30:smss.exe                                 280      4      5     30 2019-11-11 20:49:19 UTC+0000
 0x86b468c0:explorer.exe                             1988   1908     33    727 2019-11-11 20:49:25 UTC+0000
. 0x86ae4400:vmtoolsd.exe                            1428   1988     10    217 2019-11-11 20:49:26 UTC+0000
. 0x86e1b810:KeePass.exe                             3620   1988     10    251 2019-11-11 20:49:46 UTC+0000
. 0x86ae4710:vm3dservice.ex                          1396   1988      5     43 2019-11-11 20:49:26 UTC+0000
 0x86556030:winlogon.exe                              540    424      6    127 2019-11-11 20:49:22 UTC+0000
 0x85fffd20:csrss.exe                                 440    424     10    220 2019-11-11 20:49:22 UTC+0000

ここで気になったのは「Keepass.exe」
今回の問題文からKeepassのデータベースを使って何かするような気がする。ここで、「Keepass.exe」とは何か参考資料をどぞ。

KeePassツールでパスワードを安全・確実に管理する − @IT

次に「Keepass.exe」がどうやって使われたか見たいのでcmdlineでチェック

$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem cmdline | grep KeePass.exe
Volatility Foundation Volatility Framework 2.6
KeePass.exe pid:   3620
Command line : "C:\Program Files\KeePass Password Safe 2\KeePass.exe" "C:\Users\HackTM\Desktop\Database.kdbx"

どうやら、「Database.kdbx」をデータベースファイルとして利用しているらしい。なので、「Database.kdbx」を取り出せるか試す。

$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem filescan | grep Database.kdbx
Volatility Foundation Volatility Framework 2.6
0x000000007da1a248      2      0 RW-rw- \Device\HarddiskVolume2\Users\HackTM\AppData\Roaming\Microsoft\Windows\Recent\Database.kdbx.lnk
0x000000007df37c88      2      0 R--r-- \Device\HarddiskVolume2\Users\HackTM\Desktop\Database.kdbx
$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem dumpfiles -Q 0x000000007df37c88 -D ./
Volatility Foundation Volatility Framework 2.6
DataSectionObject 0x7df37c88   None   \Device\HarddiskVolume2\Users\HackTM\Desktop\Database.kdbx
$ ls
HackTM.vmem  file.None.0x86551160.dat
$ mv file.None.0x86551160.dat Database.kdbx
$ file Database.kdbx
Database.kdbx: Keepass password database 2.x KDBX

「Database.kdbx.lnk」はショートカットファイルなので無視。「Database.kdbx」を取り出すことができた。
ここで、このデータベースをチェックするには「master password」が必要である。次はこの「master password」の捜索をする。 どこにあるのかよく分からなかったので、とにかく色々volatilityコマンドを試したところclipboardに何らかの文字列を見つけた。

$ volatility --profile=Win7SP1x86_23418 -f HackTM.vmem clipboard -v
Volatility Foundation Volatility Framework 2.6
Session    WindowStation Format                 Handle Object     Data                                           
---------- ------------- ------------------ ---------- ---------- --------------------------------------------------
         1 WinSta0       0xc009L               0x7017b 0xfe9a05a8                                                 
0xfe9a05b4  1c 00 02 00                                       ....
         1 WinSta0       CF_TEXT                   0xd ----------                                                 
         1 WinSta0       0x2000L                   0x0 ----------                                                 
         1 WinSta0       CF_TEXT                0x2000 ----------                                                 
         1 WinSta0       0xd0095L                  0x0 ----------                                                 
         1 WinSta0       CF_TEXT                   0x1 ----------                                                 
         1 ------------- ------------------    0xe00cb 0xffbb46b0                                                 
0xffbb46bc  64 00 6d 00 56 00 5a 00 51 00 6d 00 64 00 7a 00   d.m.V.Z.Q.m.d.z.
0xffbb46cc  4f 00 6c 00 55 00 72 00 63 00 45 00 42 00 6c 00   O.l.U.r.c.E.B.l.
0xffbb46dc  52 00 6a 00 38 00 37 00 64 00 48 00 51 00 33 00   R.j.8.7.d.H.Q.3.
0xffbb46ec  55 00 53 00 56 00 42 00 49 00 6e 00 00 00         U.S.V.B.I.n...
         1 ------------- ------------------    0xd0095 0xfddf5300                                                 
0xfddf530c  09 04 00 00                                       ....
         1 ------------- ------------------    0xb0137 0xfd4b47b0                                                 
0xfd4b47bc  00 00 00 00 78 00 00 00 01 00 00 00 01 00 00 00   ....x...........
0xfd4b47cc  00 00 00 00 00 00 00 00 0d 00 37 71 00 00 00 00   ..........7q....
0xfd4b47dc  01 00 00 00 ff ff ff ff 01 00 00 00 01 00 00 00   ................
0xfd4b47ec  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfd4b47fc  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfd4b480c  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfd4b481c  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0xfd4b482c  00 00 00 00 00 00 00 00                           ........

なんとなく、これがパスワードのような気がしなくもない。

$ strings HackTM.vmem | grep -20 dmVZQ
(snip)
%XPOIo
OOIo
LOPI
"F?N>
%%    N
W;>-
!#7>"
444K91/
O8!YHn
40.&`?
40.&0
pA)0
1J_'"
];NS+
(&-.HTA
a,+-$
#"#6
vspscc
[~ZV
copypaste.transport
dmVZQmdzOlUrcEBlRj87dHQ3USVBIn
or.lnk
ons%29.lnk
p~ZV
    ~ZV
mpleSock: Couldn't bind on source port 1023, error 10013, An attempt was made to access a socket in a way forbidden by its access permissions
powershell/windows%20powershell.lnk".
lnk".
.~ZV
~ZVo
IPlatformGetExecInfoHash: Getting exec info hash for URL "file:///c:/programdata/microsoft/windows/start%20menu/programs/accessories/windows%20powershell/windows%20powershell%20ise.lnk".
IPlatformGetExecInfoHash: Getting exec info hash for URL "file:///c:/programdata/microsoft/windows/start%20menu/programs/accessories/windows%20powershell/windows%20powershell%20ise.lnk".
KEEPAS~1
KeePass.exe
/C:\
PROGRA~1
KEEPAS~1
KeePass.exe
/C:\
PROGRA~1
KEEPAS~1

他にも2回ほど使用しているようだが、「Keepass.exe」でも使用しているように思える。ということでこれが「master password」だと仮定して進めていく。
次に、データベースを開くのだが「keepass2」が必要なのでインストールの参考にしたリンクを貼っておく。

Linux Mint 18: パスワード一元管理ツール「KeePass2」の使い方 | 221B Baker Street
インストールが完了したならばデータベースを開いてみる。

$ keepass2 Database.kdbx

これで、GUIが出てくるので「master password」だと思われる「dmVZQmdzOlUrcEBlRj87dHQ3USVBIn」を入力して「OK」を押すとデータベースが確認できる。

f:id:Zarat:20200302155916p:plain
KeePassデータベースを開いてみた
このようにデータベースを開くと、「Jason」のところにAttachmentがあるので、右クリックで「Save Attached File(s) To」を選択してファイルを抽出する。抽出したファイルを確認する。

$ file nothinghere.7z
nothinghere.7z: 7-zip archive data, version 0.4

取り出した7zファイルはパスワードが必要だが、先ほど「dmVZQmdzOlUrcEBlRj87dHQ3USVBIn」は何回か使い回されているのを確認したので、7zにも使用してみる。

$ 7za x nothinghere.7z

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, 234 bytes (1 KiB)

Extracting archive: nothinghere.7z
--
Path = nothinghere.7z
Type = 7z
Physical Size = 234
Headers Size = 154
Method = LZMA2:12 7zAES
Solid = -
Blocks = 1


Enter password (will not be echoed):
Everything is Ok   

Size:       72
Compressed: 234
$ ls
Database.kdbx  HackTM.vmem  nothinghere.7z  nothinghere.txt
$ cat nothinghere.txt
HackTM{d14c02244b17f4f9dfc0f71ce7ab10e276a5880a05fca64d39a716bab92cda90}

flag: HackTM{d14c02244b17f4f9dfc0f71ce7ab10e276a5880a05fca64d39a716bab92cda90}


教訓

暗号化しても、メモリダンプ取っちゃえば関係ねぇ。

他の人のwriteupを読んでみて

人によってはkdbxファイルの仕組みをしっかりと理解した上で、Keepassデータベースがロードされているところを探しパスワードをを発見するなどもありました。Keepassデータベースのロード部分から、「master password」やファイル名を探し、実体を「KeePass」プロセスのメモリダンプからカービングすることもあるかもしれないので色々と資料を残しておきます。

kdbxに関する資料

Keepass file format explained · GitHub

KDBX v2 File Format · Stoom/KeePass Wiki · GitHub

他のwriteupと過去のKeePass問

CTFtime.org / HackTM CTF Quals 2020 / Find My Pass / Writeup

- Find My Pass

Find My Pass - HackTM CTF Quals 2020 | bi0s

SHX7 : for300-go_deeper