@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

ActivitiesCache.dbとアクティビティ削除(3)

先週の続きです。

OSの日付を6月25日へ変更し、レコード削除を発生させます。

f:id:hideakii:20180610093550p:plain

OSを再起動し、-wal ファイルがActivitiesCache.dbへ反映された状態にします。

f:id:hideakii:20180610094210p:plain

ActivitiesCache.dbファイルをHEXで参照し、ファイル名を検索してみます。

DeleteSample.jpgを発見できます。

f:id:hideakii:20180610094732p:plain

 更に古い情報もまだ残っていますね。

f:id:hideakii:20180610100929p:plain

 さて、これらの削除レコードを復元するにはどうするのが良いでしょうか?

削除レコードを復元できるツールは幾つかありますので、今後色々と試してみたいと思います。

f:id:hideakii:20180610102943p:plain

 

 

参考URL:

SQLite database format - ForensicsWiki

 

github.com

 

sandersonforensics.com

 

f:id:hideakii:20180610093502j:plain

ActivitiesCache.dbとアクティビティ削除(2)

先週の続きです。

テスト環境は先週からずっとシャットダウンしていましたので、先ほど起動しました。

アクティビティの状態を確認します、アクティビティには何も表示されません。

f:id:hideakii:20180602080838p:plain

ActivitiesCache.dbファイルをエクスポートします。
ActivitiesCache.dbファイルの最終更新日時は5月26日のままです。(-walファイルは現在の日付)

f:id:hideakii:20180602081157p:plain

ジャーナルを含めてActivitiesCache.dbファイルを参照します。

最初に、Activityテーブルを参照します。38番レコードが、先週削除したサンプルですが、レコード内容を確認できます。 

f:id:hideakii:20180602082148p:plain

 ActivityOperationテーブルも同様に確認すると、レコードを確認できます。

f:id:hideakii:20180602082613p:plain

 日付を変更してから、OS[を再起動します。(ExpirationTime⇒1529875249⇒Mon, 25 June 2018 06:20:49 +0900)

f:id:hideakii:20180602083022p:plain

ActivitiesCache.dbファイルをエクスポートし、ジャーナルを含めて参照します。

この日時では、レコードが削除されている事を確認できます。

f:id:hideakii:20180602084834p:plain

テストファイルのタイムスタンプを確認します、ジャーナルだけが新しい日付です。

f:id:hideakii:20180602085334p:plain

 ジャーナルファイルを削除し、ActivitiesCache.dbファイルだけを参照してみます。

削除前のレコードを確認できます。 

f:id:hideakii:20180602085525p:plain

ジャーナルが反映されていない状況では、ジャーナル無しでファイルを参照する必要がありますね。

削除レコードの復元が可能かは確認していません。

参考URL:

 Write-Ahead Logging

 

f:id:hideakii:20180602080608j:plain

ActivitiesCache.dbとアクティビティ削除

アクティビティを削除し、ActivitiesCache.db内でどのような変化が発生するかを確認します。テスト環境は Win 10 1803 です。

 サンプルのJPEG画像ファイルを参照し、アクティビティを作成します。

f:id:hideakii:20180526062232p:plain

Activityテーブルでレコードを確認します。38番レコードにJPEG画像ファイルの情報があります。

f:id:hideakii:20180526063200p:plain

アクティビティから項目を削除します。

f:id:hideakii:20180526063510p:plain

 Activityテーブルで38番レコードを再度確認します。(ジャーナルファイルを含めてデータベースファイルを参照)

f:id:hideakii:20180526063959p:plain

レコードが残っており、情報を確認する事ができます。

また、ActivityOperationテーブルに、レコードが追加されている事を確認できます。

f:id:hideakii:20180526065029p:plain

ActivityOperationテーブルには、OperationTypeというカラムがあります。3は削除操作という意味でしょうか?

f:id:hideakii:20180526065723p:plain

アクティビティを一つ削除しましたが、このテーブルには2つのレコードが登録されています。

また、これら2件のレコードについては、Etag値はActivityテーブルとActivityOperationテーブルで異なるようです。

先週テストしたアクティビティのデータを削除してみます。

f:id:hideakii:20180526070643p:plain

 

f:id:hideakii:20180526070728p:plain

Activityテーブルでは、削除したアクティビティに関する情報を確認できます。

f:id:hideakii:20180526071318p:plain

 ActivityOperationテーブルを確認します。AppActivityIdは同じですが、ActivityType 6のレコードだけが追加されています。ActivityType 5 のレコードは追加されていません。

f:id:hideakii:20180526071751p:plain

いずれのレコードも、OperationTypeは3になっています。

 

これらのレコードが本当に削除されるのは何時でしょうか?

 

参考URL:

 

 

f:id:hideakii:20180526061902j:plain

Win 10 1803 とActivitiesCache.db

Windows 10 Ver 1803 の Timeline 機能が利用している  ActivitiesCache.db を確認したいと思います。

サンプルのアクティビティを作成します。Photosアプリケーションでサンプル画像を参照します。

f:id:hideakii:20180519063905p:plain

ActivitiesCache.db ファイルは下記フォルダにあります。(ジャーナルファイルもありますね)

C:\Users\forensics\AppData\Local\ConnectedDevicesPlatform\L.forensics

f:id:hideakii:20180519064231p:plain

DB Browser for SQLite ツールを利用し、ActivitiesCache.dbファイルを参照します。

f:id:hideakii:20180519064941p:plain

Activityテーブルを参照します。

f:id:hideakii:20180519065240p:plain

AppIDのカラムでアプリケーション名などを確認できます。

[{"application":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App","platform":"windows_universal"},{"application":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App","platform":"packageId"},{"application":"","platform":"alternateId"}]

Payloadカラムを参照します。

f:id:hideakii:20180519065549p:plain

Photosアプリケーションで参照していたJPEGファイルの情報を確認できます。日本語文字列をファイル名に含めていますが、文字コードはUTF-8です。

{"displayText":"sample(サンプル).jpg","activationUri":"ms-shellactivity:","appDisplayName":"Photos","description":"C:\\Users\\forensics\\Pictures\\sample(サンプル).jpg","backgroundColor":"black","contentUri":"file:%7B33E28130-4E1E-4676-835A-98395C3BC3BB%7D/sample(サンプル).jpg","shellContentDescription":{"FileShellLink":"MBAAAEAFCAAAAAAAADAAAAAAAY0gAAAAgAAAAwjMu1n7uPdAzaBQF7u7THQGZCXfu7+0BAA8JCAAAAAABAAAAAAAAAAAAAAAAAAAAQRAUAwHQB+TQDi66kGEiiNCAsCMw0pOA4CgUrTrkkWpwUEmhvqA5HkeoaCABAgJA8uvRAAAAIXmFYP7uPdAq/o8g1u7THw0ttWYt7+0BQBAEDgMAAA8JCgsMRvqgAwUB1EUMVkfx4iSQdEAAIFAJAABA8uvyyE9qKLTqsqLAAAAVKWAAAAABAAAAAAAAAAAAAAAAAAAAcO/dAwcAEGAtBAcAwGAlBAKAULMzDz1wsOMpAgLAoGAwBwZAAAAcAgVAAAAaAw7+KAABBAcAAHAYBANAMDAoBgbAgHA0BgYAkHA5BAcAMHA2AgMAoGAoBQZAkDAzBQcAAHAkBgeAgHAuBQMAcDA5AAMAoHAlBAdAMGAAAAHAAAAADAAAQCAAAQAAAAAkAAAAUDAAAAAAAAA8CAAAIGAAAgvAAAARAAAAMAAAAw+loubQAAAAAwQ6wVVzVmczxlZvJXZuNXajNHXQl2Y0VnclNHXzFWbwxWZo8zP/8TKuoGcnBwQAoDAcBQVAMHAlBgcAMHAcBgZA8GAyBQZA4GAzBQaAMGAzBAXAAFApBwYAQHA1BgcAUGAzBAXAMHAhBQbAAHAsBQZAgCA1Cz8wcNMrDTKA4CAqBAcAcGAAAAAAAAAgBAAAMAAAAKWAAAAAAAAAQWZztGdvBXLyETO2EnN4AAuQpo/RFeKAp5UKhgCWucHr/GAGFuWoHxktgAAnwcsegLUK6fUhnCQaOlSIoglL3x6vBgRhrF6RMZLIAwJMHrHFBAAAkAAAAaOAAAAxMFUTFrFtRUrNCHSniEQuQaP4xYHAAAAoBAAAAASAAAADcrWtCAAAAAAAAmIAAAAAAAAAAAAAAAAAAAAAA"}}

 contentUriを確認します。GUID 33E28130-4E1E-4676-835A-98395C3BC3BB は Pictures フォルダを意味しています。

"file:%7B33E28130-4E1E-4676-835A-98395C3BC3BB%7D/sample(サンプル).jpg"

FileShellLink項目が興味深いです。
Base64でエンコードされたバイナリデータだと思われますが、このデータは何でしょうかね?

{"FileShellLink":"MBAAAEAFCAAAAAAAADAAAAAAAY0gAAAAgAAAAwjMu1n7uPdAzaBQF7u7THQGZCXfu7+0BAA8JCAAAAAABAAAAAAAAAAAAAAAAAAAAQRAUAwHQB+TQDi66kGEiiNCAsCMw0pOA4CgUrTrkkWpwUEmhvqA5HkeoaCABAgJA8uvRAAAAIXmFYP7uPdAq/o8g1u7THw0ttWYt7+0BQBAEDgMAAA8JCgsMRvqgAwUB1EUMVkfx4iSQdEAAIFAJAABA8uvyyE9qKLTqsqLAAAAVKWAAAAABAAAAAAAAAAAAAAAAAAAAcO/dAwcAEGAtBAcAwGAlBAKAULMzDz1wsOMpAgLAoGAwBwZAAAAcAgVAAAAaAw7+KAABBAcAAHAYBANAMDAoBgbAgHA0BgYAkHA5BAcAMHA2AgMAoGAoBQZAkDAzBQcAAHAkBgeAgHAuBQMAcDA5AAMAoHAlBAdAMGAAAAHAAAAADAAAQCAAAQAAAAAkAAAAUDAAAAAAAAA8CAAAIGAAAgvAAAARAAAAMAAAAw+loubQAAAAAwQ6wVVzVmczxlZvJXZuNXajNHXQl2Y0VnclNHXzFWbwxWZo8zP/8TKuoGcnBwQAoDAcBQVAMHAlBgcAMHAcBgZA8GAyBQZA4GAzBQaAMGAzBAXAAFApBwYAQHA1BgcAUGAzBAXAMHAhBQbAAHAsBQZAgCA1Cz8wcNMrDTKA4CAqBAcAcGAAAAAAAAAgBAAAMAAAAKWAAAAAAAAAQWZztGdvBXLyETO2EnN4AAuQpo/RFeKAp5UKhgCWucHr/GAGFuWoHxktgAAnwcsegLUK6fUhnCQaOlSIoglL3x6vBgRhrF6RMZLIAwJMHrHFBAAAkAAAAaOAAAAxMFUTFrFtRUrNCHSniEQuQaP4xYHAAAAoBAAAAASAAAADcrWtCAAAAAAAAmIAAAAAAAAAAAAAAAAAAAAAA"}

HEXでデコードすると下記になるようです。

30 10 00 00 40 05 08 00 00 00 00 00 00 30 00 00 00 00 01 8d 20 00 00 00 80 00 00 03 08 cc bb 59 fb b8 f7 40 cd a0 50 17 bb bb 4c 74 06 64 25 df bb bf b4 04 00 3c 24 20 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 04 40 50 0c 07 40 1f 93 40 38 ba ea 41 84 8a 23 42 02 c0 8c c3 4a 4e 03 80 a0 52 b4 eb 92 45 a9 c1 41 26 86 fa 80 e4 79 1e a1 a0 80 04 08 09 03 cb af 44 00 00 00 85 e6 15 83 fb b8 f7 40 ab fa 3c 83 5b bb 4c 7c 34 b6 d5 98 b7 bf b4 05 00 40 10 38 0c 00 00 3c 24 28 2c 31 1b ea 80 0c 14 07 51 14 31 59 1f c7 88 92 41 d1 00 00 81 40 24 00 01 03 cb af cb 21 3d a8 a2 d3 aa ca 8b 00 00 00 54 a5 80 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 c3 bf 74 0c 1c 00 41 80 b4 10 1c 03 01 80 94 10 0a 01 42 cc cc 3c f5 c2 c3 8c a4 08 0b 02 81 80 c0 1c 19 00 00 00 70 08 15 00 00 00 68 0c 3b f8 a0 00 04 10 1c 00 01 c0 60 10 0d 00 c0 c0 a0 18 1b 02 01 c0 d0 18 18 02 41 c0 e4 10 1c 00 c1 c0 d8 08 0c 02 81 80 a0 14 19 02 40 c0 cc 14 1c 00 01 c0 90 18 1e 02 01 c0 b8 14 0c 01 c0 c0 e4 00 0c 02 81 c0 94 10 1d 00 c1 80 00 00 07 00 00 00 00 30 00 01 00 80 00 04 00 00 00 00 90 00 00 01 40 c0 00 00 00 00 00 00 f0 20 00 00 81 80 00 08 2f 00 00 00 44 00 00 00 c0 00 00 0c 3e 96 8b 9b 40 00 00 00 0c 10 eb 05 55 cd 59 9c cf 19 59 bc 95 d9 b8 d5 da 8c d1 d7 42 5d 98 d1 59 dc 94 d1 d7 cc 55 9b c3 15 99 a3 cc cf ff c4 ca ba 81 9c 9c 1c 10 02 80 c0 70 14 15 00 c1 c0 94 18 1c 00 c1 c0 70 18 19 03 c1 80 c8 14 19 03 81 80 cc 14 1a 00 c1 80 cc 10 17 00 01 40 a4 1c 18 01 01 c0 d4 18 1c 01 41 80 cc 10 17 00 c1 c0 84 14 1b 00 01 c0 b0 14 19 02 00 80 d4 2c fc c1 c3 4c ac 34 ca 03 80 80 a8 10 1c 01 c1 80 00 00 00 00 00 00 80 10 00 00 c0 00 00 02 96 00 00 00 00 00 00 01 05 99 ce d1 9d bc 15 cb c8 44 ce d8 49 cd e0 00 2e 42 9a 3f 44 57 8a 02 9e 54 2a 18 02 5a e7 07 af f1 80 18 5b 96 a0 7c 64 b6 00 00 9f 07 2c 7a 02 d4 2b a7 d4 86 70 90 68 e9 52 22 88 25 2f 7c 7a bc 18 11 86 b1 7a 44 c6 4b 20 0c 09 30 7a c7 14 10 00 02 40 00 00 06 8e 00 00 00 c4 c1 54 4c 5a c5 b5 15 2b 34 21 d2 9e 21 10 b9 06 8f e3 16 07 00 00 00 a0 10 00 00 00 12 00 00 00 0d ca d6 b4 20 00 00 00 00 00 09 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

FileShellLinkって何ですか?

参考URL:

Windows 10 Timeline Forensic Artefacts – CCL Group

 

Windows 10 Timeline Forensic Artefacts – Cyber Forensicator

 

binaryforay.blogspot.jp

 

f:id:hideakii:20180519063230j:plain

JumpList と DestList

JumpList 内の DestList を確認します。
DestListのDirectory entry(128byte)は下記になります。

f:id:hideakii:20180513134141p:plain

44006500730074004C00690073007400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ⇒ DestList
12 00 ⇒ 18(The byte size of the directory name including the end-of-string character)02 ⇒ stream
01 ⇒ black
0C 00 00 00 ⇒ 12(The directory identifier of the previous directory entry)
FF FF FF FF ⇒ The directory identifier of the next directory entry
FF FF FF FF ⇒ The directory identifier of the sub directory entry
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ⇒ Class identifier
00 00 00 00 ⇒ User flags
00 00 00 00 00 00 00 00 ⇒  Creation time
00 00 00 00 00 00 00 00 ⇒ Modification time
1C 00 00 00 ⇒ 28 (Sector identifier (SID) of the first sector of the directory)
76 08 00 00 ⇒ 2,166 (The byte size of the directory)
00 00 00 00 ⇒ Reserved

Structured Storage Viewerでも確認してみます。

f:id:hideakii:20180513140054p:plain

 「A forensic insight into Windows 10 Jump Lists」を参考に、DestListのヘッダをパースしてみます。

04 00 00 00 ⇒ 4 ⇒  Version number
0A 00 00 00 ⇒ 10 ⇒ Total number of current Entries
04 00 00 00 4 ⇒ Total number of pinned Entries
8F C2 AA 42 ⇒  Unknown value
0B 00 00 00 00 00 00 00 ⇒ 11 ⇒ Last Issued Entry ID number
1C 00 00 00 00 00 00 00 ⇒ 28 ⇒ Number of add/delete/re-open actions

 「A forensic insight into Windows 10 Jump Lists」を参考に、DestList Entryをパースします。

76 09 DE 3D 94 6C 6C EF ⇒ A checksum or hash of the Entry
0A 51 AE 1B E0 3A E1 4A BD AB 84 21 59 48 3E 0B ⇒ New Volume ID
29 48 53 A2 AD C1 E7 11 A2 16 08 00 27 A8 3F 6E ⇒ New Object ID
0A 51 AE 1B E0 3A E1 4A BD AB 84 21 59 48 3E 0B ⇒  Birth Volume ID
29 48 53 A2 AD C1 E7 11 A2 16 08 00 27 A8 3F 6E ⇒  Birth Object ID
64 65 73 6B 74 6F 70 2D 69 36 6D 65 6F 36 34 00 ⇒ desktop-i6meo64. ⇒ NetBIOS Name padded with zero
07 00 00 00 ⇒ 7 ⇒  Entry ID number
00 00 00 00 00 00 B8 41 ⇒ ?
3B 09 3F B2 BE 55 D3 01 ⇒ 11/4/2017 10:46:04 PM ⇒ MSFILETIME of last recorded access
FF FF FF FF ⇒ Entry pin status 
02 00 00 00 ⇒ ?
08 00 00 00 ⇒ (access count)
00 00 00 00 00 00 00 00 
07 00 ⇒ Length of Unicode string data
43 00 3A 00 5C 00 63 00 61 00 73 00 65 00 ⇒ C.:.\.c.a.s.e.

Object IDのタイムスタンプを確認します。

29 48 53 A2 AD C1 E7 11

29 48 53 A2 AD C1 E7 01

137291265154959401 - 5748192000000000

131543073154959401

01D355BA64108829

Sat, 04 November 2017 22:15:15 UTC

 同じ内容を JLECmd で確認できます。ObjectIDのタイムスタンプはCreateed on:となります。

f:id:hideakii:20180513143947p:plain

JumpListViewではLast modifiedがRecord Timeになります。

f:id:hideakii:20180513144344p:plain

 Plaso 20180127 の出力結果は下記になります。LOGのタイムスタンプがLast modifiedですね。

f:id:hideakii:20180513145552p:plain

 

参考URL:

 

binaryforay.blogspot.jp

http://cyberforensicator.com/wp-content/uploads/2017/01/1-s2.0-S1742287616300202-main.2-14.pdf

 

www.nirsoft.net

https://tzworks.net/prototypes/jmp/jmp.users.guide.pdf

 

 

f:id:hideakii:20180513094401j:plain

JumpList と Stream

JumpList と The allocation table」の続きです。

次のDirectory entry(128byte)をパースしてみます。 

f:id:hideakii:20180506170331p:plain

31000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ⇒ 1

04 00 ⇒ The byte size of the directory name including the end-of-string character

02 ⇒ The type of the directory entry ⇒ stream

01 ⇒ The node color of the directory entry.⇒ Black

FF FF FF FF ⇒ The directory identifier of the previous directory entry

FF FF FF FF ⇒ The directory identifier of the next directory entry

FF FF FF FF ⇒ The directory identifier of the sub directory entry

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ⇒ Class identifier

00 00 00 00 ⇒ User flags

00 00 00 00 00 00 00 00 ⇒ Creation time (FILETIME)

00 00 00 00 00 00 00 00 ⇒ Modification time(FILETIME)

00 00 00 00 ⇒ Refers to the SID of a stream or the SID of short-stream container stream

BD 01 00 00 ⇒ Refers to the size of a stream or the size of a short-stream container stream ⇒ 445

00 00 00 00 ⇒ Reserved

上記結果から、このエントリは445バイトのストリームとなっています。

Root Entry の Sector identifier (SID) of the first sector of the directory は 3 です、セクタ 3 を確認します。LNK ファイルのシグネチャが登場します。

f:id:hideakii:20180506172145p:plain

ヘッダによれば、Size of a short-sector (mini-sector)は64バイトとなっています。

SSATを確認します。チェーンは0⇒1⇒2⇒3⇒4⇒5⇒Dと構成されています。

f:id:hideakii:20180506172738p:plain

 まず、0⇒1⇒2⇒3⇒4⇒5の 384 バイトを確認します。

f:id:hideakii:20180506173120p:plain

 セクタDで残りの64バイトを確認します。(ストリームのサイズは445バイト)

f:id:hideakii:20180506173308p:plain

Structured Storage Viewer でデータを確認してみます。 同じデータですね。

f:id:hideakii:20180506173846p:plain

このJumpListファイル内には、LNKデータがストリームのエントリとして保存されている事を確認できました。

 

次へ続きます。

 

参考URL: 

github.com

binaryforay.blogspot.jp

 

 

f:id:hideakii:20180506155351j:plain

JumpList と The allocation table

JumpListのファイル構造続き。SAT(Sector Allocation Table)を確認します。

Object Linking and Embedding (OLE) Compound File (CF) format specification」を参照しています。

 Master Sector Allocation Table (MSAT)はオフセット76から開始されており、オフセット76からの4バイトは00 00 00 00である事から、セクタ位置は0となっています。

f:id:hideakii:20180428182039p:plain

 セクタ位置0を確認します。Sector identifier は 0xfffffffd (-3)です。

0xfffffffd (-3) ⇒ Marks the sector as used for the SAT(Sector Allocation Table)

f:id:hideakii:20180428182313p:plain

次にセクタ1を確認します。チェーンの値は06です。

f:id:hideakii:20180428184601p:plain

 セクタ 1 を確認します。

directory entryがあります、directory entryは128バイトです。 

f:id:hideakii:20180428185201p:plain

最初のdirectory entryをパースしてみます。

52 00 6F 00 6F 00 74 00 20 00 45 00 6E 00 74 00 72 00 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ⇒ The directory name in UTF-16 ⇒ R.o.o.t. .E.n.t.r.y.

16 00 ⇒ The byte size of the directory name including the end-of-string character ⇒ 22

05 ⇒ The type of the directory entry ⇒ root storage

00 ⇒ The node color of the directory entry. ⇒ red

FF FF FF FF ⇒ -1 ⇒ The value is -1 if no previous directory entry is present

FF FF FF FF ⇒ -1 ⇒ The value is -1 if no next directory entry is present

04 00 00 00 ⇒ The directory identifier of the sub directory entry

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ⇒ Class identifier

00 00 00 00 ⇒ User flag

00 00 00 00 00 00 00 00 ⇒ Creation time

E0 ED 7A A6 F7 D9 D3 01 ⇒ Modification time(FILETIME) ⇒ 4/22/2018 5:06:19 AM

03 00 00 00 ⇒ Sector identifier (SID) of the first sector of the directory

40 20 00 00 ⇒ The byte size of the directory ⇒ 8256

00 00 00 00 ⇒ Reserved

 

続きます。

 

参考URL:

github.com

binaryforay.blogspot.jp

articles.forensicfocus.com

 

f:id:hideakii:20180428125811j:plain

JumpList と OLECF file header

 これも古い話題ですが :-)、JumpListのファイル形式について確認します。
JumpListファイルの詳細については、参考URLの記事を参照してください。

 

下記図は、Windows 10環境でAutomaticDestinationsフォルダ配下にあるf01b4d95cf55d32a.automaticDestinations-msファイルを参照しています。

AppID が「f01b4d95cf55d32a」ですので、Explorer の JumpList ファイルとなります。

f:id:hideakii:20180422142142p:plain

ファイルヘッダのシグネチャは D0 CF 11 E0 A1 B1 1A E1 となっており、OLECFである事が分かります。OLECF形式については、マイクロソフトが仕様を公開しています。

Object Linking and Embedding (OLE) Compound File (CF) format specification を参照し、ファイルヘッダ部分をパースします。

D0 CF 11 E0 A1 B1 1A E1 The signature (magic identifier)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Class identifier (GUID)
3E 00 Revision number of the file format (minor version) ⇒ 62
03 00 Version number of the file format (major version)
FE FF Byte order identifier ⇒ \xfe\xff little endian
09 00 Size of a sector in the compound document file in power-of-two ⇒ 512byte
06 00 Size of a short-sector (mini-sector) in the short-stream container stream in power-of-two ⇒ 64byte
00 00 00 00 00 00 Reserved
00 00 00 00  Number of Directory Sectors.
01 00 00 00 Number of FAT Sectors
01 00 00 00 First Directory Sector Location
00 00 00 00 Transaction Signature Number
00 10 00 00 Mini Stream Cutoff Size ⇒ 4096
02 00 00 00 First Mini FAT Sector Location ⇒ 2
02 00 00 00 Number of Mini FAT Sectors ⇒ 2
FE FF FF FF First DIFAT Sector Location
00 00 00 00 Number of DIFAT Sectors
DIFAT (436byte)

f:id:hideakii:20180422145112p:plain

 Master Sector Allocation Table (MSAT)はオフセット76から開始されます。下記では、オフセット76からの4バイトは00 00 00 00となっており、セクタ位置は0となっています。 

f:id:hideakii:20180422151312p:plain

最初のセクタ位置を確認します。

f:id:hideakii:20180422152546p:plain

Sector identifier は 0xfffffffd (-3)となっており、Marks the sector as used for the SAT(Sector Allocation Table)である事が分かります。

更に詳細に追跡する方法は、「Jump lists in depth: Understand the format to better understand what your tools are (or aren't) doing」で詳しく解説されています。

 

来週、続きを確認する予定です。

 

参考URL:

 

windowsir.blogspot.jp

windowsir.blogspot.jp

binaryforay.blogspot.jp

 

blog.didierstevens.com

 

www.blackbagtech.com

github.com

www.nirsoft.net

https://msdn.microsoft.com/en-us/library/dd942138.aspx

 

github.com

www.4n6k.com

 

 

f:id:hideakii:20180422075526j:plain

Registry MinerとTime stamp

Registry Miner を利用し、レジストリファイルからタイムスタンプを採掘します。

サンプルのSYSTEMハイブに対して、Registry Miner を実行します。”starting timestamp”で指定した日時以降の、タイムスタンプを含むキーや値が採掘されます。

# ./registry-miner.py 20180101 ./reg/SYSTEM Timestamp.csv

出力結果のCSVファイルを参照し、例としてBAMキーの行を確認します。 

./reg/SYSTEM,ControlSet001\Services\bam\UserSettings\S-1-5-21-3895603692-3337950920-141663326-1001,
value:
\Device\HarddiskVolume2\Program Files\AccessData\FTK Imager\FTK Imager.exe,
2018-04-07 10:21:05.758096,
FILETIME,
value_data_bin,2,"b'\x9e\xeb>#Z\xce\xd3\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00' (ts_pos=0, ts_len=8, ctx_start=0)"

Note:
ExcelでCSVファイルを参照すると、タイムスタンプは丸めて表示されます。

f:id:hideakii:20180414180523p:plain

 同じ値をRegistry Explorerでも確認してみます。

f:id:hideakii:20180414181428p:plain

 AppCompatCache値のように、複数のタイムスタンプが含まれる場合は1行だけ出力されます。

./reg/SYSTEM,ControlSet001\Control\Session Manager\AppCompatCache,
value: AppCompatCache,
2018-04-07 12:05:40.789000,
FILETIME,
value_data_bin,2,"b's\x00S\x00r\x00v\x00.\x00e\x00x\x00e\x00P\xa6t\xbfh\xce\xd3\x01\x18\x00\x00\x00\x00\x02\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00' (ts_pos=226, ts_len=8, ctx_start=210)"

Registry MinerはGUIDTIME 形式のタイムスタンプも採掘してくれます。
サンプルのSYSTEMハイブ内では、USBに関連した値で出力がありました。

./reg/SYSTEM,ControlSet001\Enum\USBSTOR\Disk&Ven_BUFFALO&Prod_USB_Flash_Disk&Rev_4000\A260000000885020&0\Device Parameters\Partmgr,
value:
DiskId,
2018-03-23 22:43:02.491098,
GUIDTIME,
value_data_str,2,

f:id:hideakii:20180414183457p:plain

 

UNIXTIME形式の採掘結果を確認します。

 ./reg/SYSTEM,ControlSet001\Services\Dnscache\Parameters\Probe\{70b977cd-a94c-4efa-b672-c495177be3ed},
value: LastProbeTime,
2018-04-14 16:36:19,
UNIXTIME,
value_data_int,2,

f:id:hideakii:20180414191506p:plain

サンプルのNTUSER.DATファイルを利用して、残りのタイムスタンプ形式を確認します。

 

ISOTIME形式の採掘結果を確認します。 

./reg2/NTUSER.DAT,Software\Microsoft\Windows\CurrentVersion\WindowsUpdate,
value:
LastAutoAppUpdateSearchSuccessTime,
2018-04-14 07:42:32,
ISOTIME,
value_data_str,2,

 

f:id:hideakii:20180414193833p:plain

 

SYSTEMTIME形式の採掘結果を確認します。 

./reg2/NTUSER.DAT,Software\Microsoft\MicrosoftEdge\BrowserEmulation,
value:
CVListPingLastYMD,
2018-04-07 09:21:38,
SYSTEMTIME,
value_data_bin,2,"b'\xe2\x07\x04\x00\x06\x00\x07\x00\t\x00\x15\x00&\x00\x01\x01' (ts_pos=0, ts_len=16, ctx_start=0)"

 

f:id:hideakii:20180414194250p:plain

E207 ⇒Year 2018
0400 ⇒ Month 04
0600 ⇒ DayOfWeek
0700 ⇒ Day 7
0900 ⇒ Hour 9
1500 ⇒ Minute 21
2600 ⇒ Second 38
0101 ⇒ Milliseconds 257

 

 Registry Minerを利用すれば、新たなタイムスタンプの発掘が可能になりそうですね。

Registry Miner に感謝!

 

By the way, I love Minecraft!

参考URL:

github.com

 

SYSTEMTIME Structure1

f:id:hideakii:20180414173652j:plain

LNK と Time stamp (FAT date and time)

LNKファイル内のShell Itemに含まれる、タイムスタンプ形式を確認します。

LEcmdを利用し、LNKファイルに含まれるタイムスタンプを確認します。フォルダCaseと、P1060117.jpgのタイムスタンプ情報を確認できます。

f:id:hideakii:20180407180510p:plain

LNKとShell item」を参考に、Caseフォルダに関するタイムスタンプを確認します。

874C7732 Last modification date and time
644B2CB4 Creation date and time
874C7732 Last access date and time

f:id:hideakii:20180407181619p:plain

タイムスタンプ情報は「Contains a FAT date and time in UTC」形式となっています。TimeLoadを利用し変換します。

874C7732 ⇒ 2018-04-07 06:19:46 Last modification date and time(UTC)

f:id:hideakii:20180407182323p:plain

644B2CB4 ⇒ 2017-11-04 22:33:24 Creation date and time (UTC)
874C7732 ⇒ 2018-04-07 06:19:46 Last access date and time (UTC)

 

NTFSボリューム上にある、Caseフォルダのタイムスタンプを確認します。

f:id:hideakii:20180407182959p:plain

NTFS上ではCaseフォルダのData Modified が 06:19:45 となっていますが、LNK内Shell Itemのタイムスタンプは 06:19:46 となっています。

これは、下記URLで説明されている、タイムスタンプ分解能の違いによる影響ですかね。

https://support.microsoft.com/help/402160

 

PlasoでこのLNKファイルのタイムラインを作成すると、下記の出力結果を得られます。MFTのタイムラインと一緒に確認する場合、タイムスタンプ分解能により、差異が出ますね。f:id:hideakii:20180407210338p:plain

 

<補足>

Property Storeではタイムスタンプの保存形式が異なります。

例として、P1060117.jpg.LNK のProperty Storeを確認してみます。

b725f130-47ef-101a-a5f1-02608c9eebac\14 Date Modified の値は、04/07/2018 06:19:45 になっています。

f:id:hideakii:20180407184238p:plain

HEXデータを確認してみます。下記では、8バイト長のタイムスタンプ(FILETIME)が記録されています。

f:id:hideakii:20180407185557p:plain

 タイムスタンプを変換します。2018-04-07 06:19:45.6168864

f:id:hideakii:20180407185813p:plain

 

 参考URL:

computerforensics.parsonage.co.uk

http://www.kazamiya.net/en/fte/type

 

windowsir.blogspot.jp

f:id:hideakii:20180407190851j:plain