$ATTRIBUTE_LIST and deleted record
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
I will use the sample VHD Disk created last week.
$ATTRIBUTE_LIST of FILE record 39 is as follows. Several $FILE_NAME saved in FILE record number 40.
Filename00000001.txt is saved in FILE record number 40. At the end of this FILE record, the $DATA attribute is stored.
Delete filename00000001.txt and confirm the FILE record 40.
You can check the character string of filename00000001.txt with Slack of FILE record number 40.
However, since only one $FILE_NAME attribute has been deleted, we can not find filename00000001.txt as a deleted file.
Is it possible to delete two FILE records referenced by $ATTRIBUTE_LIST at the same time? I'd like to verify whether an inconsistency occurs due to deleting and overwriting the FILE record referenced by $ATTRIBUTE_LIST.
To test another scenario, return the VHD disk to its original state.
Delete all files.
Let's check the state after deletion....Unfortunately, it was different from what I expected.
Is it the result of the Del command sequentially deleting files? , Only filename 00000007.txt file will be displayed.
I will try another method.
Check the status of $ATTRIBUTE_LIST.
FILE records 40 and 41 are used.
Delete folder1.
The following figure is the result I was expecting.....Aaaa, I misunderstood the result.
The above figure contained $I30 parsing result. When referenced by other tools, only filename0000007.txt is displayed in the deleted file.
I have created another VHD disk.
$SIA of filename00000006.txt is stored in FILE record 39, and $FILE_NAME is stored in FILE record 40.
Create a new file and overwrite the FILE record 39.
FILE record 40 remains, but Autopsy can not refer to filename00000006.txt.
Export $MFT and parse it with fte tool. I can find filename00000006.txt. Thank you fte, I wanted to confirm this result.
Overwrite the FILE record with another pattern.
$SIA is stored in FILE record 40, $FILE_NAME is stored in FILE record 39.
Delete files other than filename00000001.txt.
Create a file and overwrite the FILE record 39. $SIA is in FILE record 40, but $FILE_NAME does not exist. Some tools do not display $SIA in FILE record 40.
Does your favorite tool display $SIA of FILE record 40?
Well, how do I visualize the FILE record 40?
For example, there is a way to use Plas MFT parser.
>log2timeline.exe --parsers mft --artifact_filters NTFSMFTFiles c:\case\mft.plaso c:\case\Atrribute9.vhd
>psort -o l2tcsv -w c:\case\mft_timeline.csv c:\case\mft.plaso
FILE Record 40 $SIA was confirmed.
by the way,
Google Translate shows multiple candidates for a single word, but suffers from choosing which one is right. For example, check and confirm.
Reference URL:
http://www.kazamiya.net/en/fte
it appears MFTECmd behaves appropriately in this case. Tools that to not follow attribute lists to other MFT entries or manually track extension records miss data. many tools do not do this correctly pic.twitter.com/b702mh2khT
— Eric Zimmerman (@EricRZimmerman) July 7, 2018
$MFT と $ATTRIBUTE_LIST
Note:
For experimental purposes, I use Google Translate to convert Blog to English.Unfortunately, I do not know whether it was translated into an appropriate English expression.Please let me know if there is a more appropriate expression.
There are many tools to parse $MFT, but the processing result of $ATTRIBUTE_LIST varies depending on the tool.
I would like to confirm about $ATTRIBUTE_LIST.
Create a test file in the sample VHD disk.
Use the fsutil command to create several hard links.By executing the following command, the attribute will not fit all in one FILE record.
In the $MFT file, reference the FILE record of Filename 00000001.txt.
You can see that there is a $ ATTRIBUTE_LIST (0x20) attribute in the FILE record.
In the example below, this attribute is Resident.
When you refer to the same file with Autopsy, it becomes as follows.
The MFT record number of Filename 00000001.txt is 39. In addition, you can check that this file is using record number 40 as well.
(Type 48 (0x30) is the $FILE_NAME attribute.)
Reference record number 40 in the $ MFT file.
"File reference to the base FILE record" indicates 39 (0x27).
When parsing this $MFT file with fte tool, it becomes as follows.
The $FILE_NAME attribute stored in record number 40 is also displayed.
The result of parsing the same $MFT file with MFTECmd is as follows.
Both tools display seven sample files.
However, when parsing the $MFT file, depending on the tool, all file names are not displayed due to $ATTRIBUTE_LIST.
<Added 2018/7/3>
There are several tools affected by $ATTRIBUTE_LIST. One example is Plaso MFT parser.
I will try parsing $MFT using the MFT parser of plaso-20180630.
Artifacts filter is available in Plaso-20180630. I'm not familiar with it yet, but it's a very interesting feature.
c:\case\plaso-20180630-amd64>log2timeline.exe --parsers mft --artifact_filters NTFSMFTFiles c:\case\mft.plaso c:\case\Atrribute1.vhd
Use the psort command to output the timeline in l2tcsv format.
You can find file names 2 and 7, but you can not find file names 1, 3, 4, 5, and 6.
</Added>
Sample VHD file.
By the way, I did not know that the fsutil command has a layout option.
it seems that it doesn't mean anything pic.twitter.com/Nxg05FXzaL
— Costas K (@sv2hui) June 28, 2018
The Layout option seems to be available from Win 10 ver 1803.
参考URL:
MFTECmd と $EA
NTFSの$MFTファイルをパースするツール”MFTECmd”をEricさんがリリースしています。素晴らしいツールをありがとうございます!
<2018/6/27 Add>v0.2.6.0がリリースされています</add>
セキュリティキャンプ2018でE6トラックを選択する若者達には、ぜひ調査で利用していただきたいツールです。
初めて利用するので、ツール利用方法の確認と、$EA属性が確認できるかを見てみます。
まず、サンプルの画像ファイルを準備します。 ファイルサイズは33.2KBです。
この画像ファイルを、EaToolsを利用してNTFSの$EA属性へ保存します。
$MFTでFILEレコードを確認します。$EA属性が追加されている事を確認できます。
DataRunの値から、クラスタ2009にデータが保存されている事が分かります。
Autopsy 4.7.0でも確認してみます。ストリームの名前が確認できないようですが、データが存在する事は識別できます。
$MFTファイルをエクスポートし、MFTECmd 0.2.5.0でパースします。
結果を確認します。SiFlags値が数字?
<6/24 added>
SiFlags値が262176となっていました、$SI を参照すると下記の状態になっています。
00 04 00 20
File attribute flagsを参照すると0x00000020 FILE_ATTRIBUTE_ARCHIVEは確認できますが、04 00 00は記載がありません。PowerMftの説明では、ea = 0x00040000となっていますね。
次のリリースではHasEAフラグが登場ということです。これは便利です!
For example: You wont see the integer in the SIFlags column after the next release too now that i added the HasEA flag
— Eric Zimmerman (@EricRZimmerman) June 23, 2018
--deオプションを利用すれば、EA属性を確認できる事に気が付いていませんでした。
MFTECmd.exe -f c:\case\MFT\$MFT --de 39-1
次のバージョンでは下記のようになるそうです。楽しみですね!
this is in the next release. notice how you can see the bytes from the EA.
— Eric Zimmerman (@EricRZimmerman) June 23, 2018
example command to see this detail: .\MFTECmd.exe -f 'D:\SynologyDrive\MFTs\vanko\vanko_MFT' --de 0x46EE1-0x2
Get the entry and seq info from the CSV pic.twitter.com/lKltiDbC9J
</added>
もしかすると、私だけかもしれませんが、属性一覧と、DataRun値のパース結果が、MFTECmdの出力結果に含まれていると便利ではないでしょうか。
※上記で作成したサンプルVHDディスク
参考URL:
Introducing MFTECmd! Give it a whirl!! https://t.co/2OgzfctTnJ #DFIR
— Eric Zimmerman (@EricRZimmerman) June 22, 2018
ActivitiesCache.dbとアクティビティ削除(3)
先週の続きです。
OSの日付を6月25日へ変更し、レコード削除を発生させます。
OSを再起動し、-wal ファイルがActivitiesCache.dbへ反映された状態にします。
ActivitiesCache.dbファイルをHEXで参照し、ファイル名を検索してみます。
DeleteSample.jpgを発見できます。
更に古い情報もまだ残っていますね。
さて、これらの削除レコードを復元するにはどうするのが良いでしょうか?
削除レコードを復元できるツールは幾つかありますので、今後色々と試してみたいと思います。
参考URL:
SQLite database format - ForensicsWiki
ActivitiesCache.dbとアクティビティ削除(2)
先週の続きです。
テスト環境は先週からずっとシャットダウンしていましたので、先ほど起動しました。
アクティビティの状態を確認します、アクティビティには何も表示されません。
ActivitiesCache.dbファイルをエクスポートします。
ActivitiesCache.dbファイルの最終更新日時は5月26日のままです。(-walファイルは現在の日付)
ジャーナルを含めてActivitiesCache.dbファイルを参照します。
最初に、Activityテーブルを参照します。38番レコードが、先週削除したサンプルですが、レコード内容を確認できます。
ActivityOperationテーブルも同様に確認すると、レコードを確認できます。
日付を変更してから、OS[を再起動します。(ExpirationTime⇒1529875249⇒Mon, 25 June 2018 06:20:49 +0900)
ActivitiesCache.dbファイルをエクスポートし、ジャーナルを含めて参照します。
この日時では、レコードが削除されている事を確認できます。
テストファイルのタイムスタンプを確認します、ジャーナルだけが新しい日付です。
ジャーナルファイルを削除し、ActivitiesCache.dbファイルだけを参照してみます。
削除前のレコードを確認できます。
ジャーナルが反映されていない状況では、ジャーナル無しでファイルを参照する必要がありますね。
削除レコードの復元が可能かは確認していません。
参考URL:
ActivitiesCache.dbとアクティビティ削除
アクティビティを削除し、ActivitiesCache.db内でどのような変化が発生するかを確認します。テスト環境は Win 10 1803 です。
サンプルのJPEG画像ファイルを参照し、アクティビティを作成します。
Activityテーブルでレコードを確認します。38番レコードにJPEG画像ファイルの情報があります。
アクティビティから項目を削除します。
Activityテーブルで38番レコードを再度確認します。(ジャーナルファイルを含めてデータベースファイルを参照)
レコードが残っており、情報を確認する事ができます。
また、ActivityOperationテーブルに、レコードが追加されている事を確認できます。
ActivityOperationテーブルには、OperationTypeというカラムがあります。3は削除操作という意味でしょうか?
アクティビティを一つ削除しましたが、このテーブルには2つのレコードが登録されています。
また、これら2件のレコードについては、Etag値はActivityテーブルとActivityOperationテーブルで異なるようです。
先週テストしたアクティビティのデータを削除してみます。
Activityテーブルでは、削除したアクティビティに関する情報を確認できます。
ActivityOperationテーブルを確認します。AppActivityIdは同じですが、ActivityType 6のレコードだけが追加されています。ActivityType 5 のレコードは追加されていません。
いずれのレコードも、OperationTypeは3になっています。
これらのレコードが本当に削除されるのは何時でしょうか?
参考URL:
Win 10 1803 とActivitiesCache.db
Windows 10 Ver 1803 の Timeline 機能が利用している ActivitiesCache.db を確認したいと思います。
サンプルのアクティビティを作成します。Photosアプリケーションでサンプル画像を参照します。
ActivitiesCache.db ファイルは下記フォルダにあります。(ジャーナルファイルもありますね)
C:\Users\forensics\AppData\Local\ConnectedDevicesPlatform\L.forensics
DB Browser for SQLite ツールを利用し、ActivitiesCache.dbファイルを参照します。
Activityテーブルを参照します。
AppIDのカラムでアプリケーション名などを確認できます。
[{"application":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App","platform":"windows_universal"},{"application":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App","platform":"packageId"},{"application":"","platform":"alternateId"}]
Payloadカラムを参照します。
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
JumpList と DestList
JumpList 内の DestList を確認します。
DestListのDirectory entry(128byte)は下記になります。
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でも確認してみます。
「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:となります。
JumpListViewではLast modifiedがRecord Timeになります。
Plaso 20180127 の出力結果は下記になります。LOGのタイムスタンプがLast modifiedですね。
参考URL:
http://cyberforensicator.com/wp-content/uploads/2017/01/1-s2.0-S1742287616300202-main.2-14.pdf
https://tzworks.net/prototypes/jmp/jmp.users.guide.pdf
JumpList と Stream
「JumpList と The allocation table」の続きです。
次のDirectory entry(128byte)をパースしてみます。
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 ファイルのシグネチャが登場します。
ヘッダによれば、Size of a short-sector (mini-sector)は64バイトとなっています。
SSATを確認します。チェーンは0⇒1⇒2⇒3⇒4⇒5⇒Dと構成されています。
まず、0⇒1⇒2⇒3⇒4⇒5の 384 バイトを確認します。
セクタDで残りの64バイトを確認します。(ストリームのサイズは445バイト)
Structured Storage Viewer でデータを確認してみます。 同じデータですね。
このJumpListファイル内には、LNKデータがストリームのエントリとして保存されている事を確認できました。
次へ続きます。
参考URL:
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となっています。
セクタ位置0を確認します。Sector identifier は 0xfffffffd (-3)です。
0xfffffffd (-3) ⇒ Marks the sector as used for the SAT(Sector Allocation Table)
次にセクタ1を確認します。チェーンの値は06です。
セクタ 1 を確認します。
directory entryがあります、directory entryは128バイトです。
最初の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: