@port139 Blog

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

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

LNK と Property Store

LNKファイルのProperty Store構造を確認します。

サンプルJPEGファイルを準備します。このJPEGファイルはEXIF情報を含んでいます。

f:id:hideakii:20180401054953p:plain

 サンプルJPEGファイルのショートカットを作成します。

f:id:hideakii:20180401055311p:plain

作成したショートカットファイルを LEcmd でパースし、Property store data blockを確認します。Property Store dataがLNKファイル内に存在している事を確認できます。

f:id:hideakii:20180401055545p:plain

LNKファイル内の「The metadata property store data block」を確認してみます。

 シグネチャ0xa0000009をハイライトしています。

f:id:hideakii:20180401060201p:plain

最初のserialized property storageは、245バイトあります。

f:id:hideakii:20180401060956p:plain

Windows Property Store formatを参考し、パースしてみます。一部不完全な結果になっています。

F5 00 00 00 Size of the serialized property storage ⇒ 245
31 53 50 53 "1SPS" ⇒ Version
A1 1D B8 14 35 01 31 4D 96 D9 6C BF C9 67 1A 99 ⇒Format class (or property set) identifier GUID ⇒ 14b81da1-0135-4d31-96d9-6cbfc9671a99 
25 00 00 00 ⇒ 37 (長さ)
0F 01 00 00 ⇒ 271 ⇒ Manufacturer of camera
00 Reserved
1F 00 00 00 ⇒ 31 (Property value type?)

0A 00 00 00 ⇒ 10 (文字列長?)
500061006E00610073006F006E00690063000000 ⇒ Panasonic

15 00 00 00 ⇒  21 (長さ)
9A 82 00 00⇒ 33434 ⇒ Exposure Time
00 Reserved

 

<4/2追記> 

サンプルのLNKファイルを、plaso-20180127でパースした結果が下記です。Shell Itemはパースされていますが、Property Soreはパースされません。

f:id:hideakii:20180402195649p:plain

 

参考URL:

github.com

https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa965725(v=vs.85).aspx

http://www.classicshell.net/forum/viewtopic.php?f=13&t=7959

libfole/OLE definitions.asciidoc at master · libyal/libfole · GitHub

f:id:hideakii:20180401054303j:plain

LNKとShell item

LNKファイルのShell item構造を確認します。

USBメモリ上にある、Example.jpgを参照し、RecentフォルダにLNKファイルを生成します。

f:id:hideakii:20180324083000p:plain

Windows Shortcut File format specification を参考に、LNKファイルのFile headerを確認します。オフセット20からの4バイトがData flagsとなっています。 

f:id:hideakii:20180324084456p:plain

Data flags ⇒ 0x00 20 00 93 
0x00000001 HasTargetIDList
0x00000002 HasLinkInfo
0x00000010 HasWorkingDir
0x00000080 IsUnicode
0x00200000 DisableKnownFolderTracking

フラグHasTargetIDListのビットがONになっています。このフラグは、[MS-SHLLINK]: Shell Link (.LNK) Binary File Format では下記記述となっています。

The shell link is saved with an item ID list (IDList). If this bit is set, a
LinkTargetIDList structure (section 2.2) MUST follow the ShellLinkHeader.
If this bit is not set, this structure MUST NOT be present.

 ShellLinkHeaderの続きに、LinkTargetIDList structureが存在しています。オフセット76からの2バイトを確認します。IDListSize (2 bytes)は0x013D⇒317バイトとなっています。 

f:id:hideakii:20180324105701p:plain

ItemIDList (variable)とTerminalID (2 bytes)の合計317バイトは、下記でハイライトした範囲となります。

f:id:hideakii:20180324110329p:plain

データ内容を、Windows Shell Item format specificationを参考にパースしてみます。
Itemの中に、タイムスタンプ情報やNTFS file referenceを確認できます。

14 00⇒20 byte
1F Class type indicator ⇒ Root folder shell item
50 Sort index
E04FD020EA3A6910A2D808002B30309D ⇒ GUID ⇒ My Computer (Computer)

19 00⇒25 byte
2F Class type indicator ⇒Volume shell item 
453A5C00000000000000000000000000000000000000 ⇒E:\

56 00⇒86 byte
31 Class type indicator ⇒CLSID_ShellFSFolder ⇒File entry shell item 0x01 ⇒ Is directory
00 ⇒ Unknown (Empty value)
00000000 File size
774C4DB8 Last modification date and time Contains a FAT date and time in UTC
1000 File attribute flags ⇒ FILE_ATTRIBUTE_DIRECTORY
466F6C6465723100 ⇒ Folder1
4000 Extension block size ⇒ 64
0900 Extension version
0400EFBE Extension signature ⇒ File entry extension block 0xbeef0004
774C47B8 Creation date and time Contains a FAT date and time in UTC
774C4DB8 Last access date and time Contains a FAT date and time in UTC
2E00 ⇒ Windows 8.1, 10
0000
2B00000000000100 ⇒ NTFS file reference
0000000000000000
0000
00000000
1D907D00
46006F006C006400650072003100 ⇒ Folder1
0000
1600 ⇒ First extension block version offset
56 00⇒86 byte
31 Class type indicator ⇒CLSID_ShellFSFolder ⇒ 0x01 ⇒ Is directory
0000000000774C4CB81000466F6C6465723200400009000400EFBE774C4CB8774C4CB82E0000002C000000000001000000000000000000000000000000A81F930046006F006C00640065007200320000001600
62 00⇒98 byte
32 Class type indicator ⇒CLSID_ShellFSFolder ⇒ 0x02 ⇒ Is file
0000A03F00774C27B820006578616D706C652E6A706700480009000400EFBE774C37B8774C37B82E00000027000000000001000000000000000000000000000000CBF826016500780061006D0070006C0065002E006A007000670000001A00

 

LEcmdツールを使い、example.jpg.lnkファイルをパースします。

Target ID informationの項目を確認します。

f:id:hideakii:20180324083508p:plain

 

参考URL:

https://forensicswiki.org/wiki/LNK

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

github.com

github.com

https://ericzimmerman.github.io/

f:id:hideakii:20180324075823j:plain

RegistryとAccess bits

レジストリファイルのAccess Bitsを確認します。検証環境はWindows 10 1709です。

サンプルのレジストリキーをHKCU(NTUSER.DAT)配下に作成します。

f:id:hideakii:20180318072929p:plain

yarp-printを利用し、Exampleキーを作成したNTUSER.DATをパースします。ExampleキーのAccess Bits値は2となっています。
#yarp-print NTUSER.DAT

Hive information:

Last written timestamp (UTC): 1601-01-01 00:00:00
Last reorganized timestamp (UTC): 2018-03-12 09:31:35.325376

 <snip>

Key path: Example
Last written timestamp (UTC): 2018-03-17 22:04:22.066882
Access bits: 2

Value name: Example
Value type: REG_SZ
Data size: 18
Data (decoded):
Evidence\00

Windows registry file format specificationを参照し、Access bitsのオフセット位置を確認します。Access Bits値はKey nodeのオフセット14から長さ4となっています。

Registry ExplorerのTechnical detailでnk レコードを確認してみます。0x02となっている事を確認できます。<2018/3/25 追記>最新版のRegistry ExplorerではAcces Flsgsという項目で状態を確認できるようになっています。

f:id:hideakii:20180318075443p:plain

 Windows registry file format specificationでは、Access Bits が0x02の場合は下記の説明となっています。

 0x2 This key was accessed after a Windows registry was initialized with the NtInitializeRegistry() routine during the boot

NTUSER.DAT内には0x01になっているキーが無かったので、SYSTEMハイブでAccess Bitsが1のキーを確認します。下記キーはAccess Bitsが0x01です。

Key path: ControlSet001\Control\ACPI
Last written timestamp (UTC): 2017-09-29 13:47:33.433594
Access bits: 1

 Windows registry file format specificationでは、Access Bits が0x01の場合は下記の説明となっています。

0x1 This key was accessed before a Windows registry was initialized with the NtInitializeRegistry() routine during the boot

更に、Access Bitsが0x03のキーをSYSTEMハイブで確認してみます。例えばBAMキーはAccessBitsが3となっています。

Key path: ControlSet001\Services\bam
Last written timestamp (UTC): 2017-11-05 03:07:09.907890
Access bits: 3

最後に、Access Bitsが0x00のキーをNTUSER.DATハイブで確認してみます。

Last reorganized timestamp (UTC): 2018-03-12 09:31:35.325376

<snip>

Key path: Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\bat
Last written timestamp (UTC): 2018-03-03 00:38:38.119818
Access bits: 0

上記キーはAccess Bits値が0x00です。このキーは2018-03-12 09:31:35以降アクセスされていないという事になるようですね。

詳しくは@errno_failさんのTweetを参照していただけると良いかと思います。

参考URL:

 

github.com

binaryforay.blogspot.jp

f:id:hideakii:20180318083553j:plain

 

Registry Transaction LogとPlaso

 Registry Explorerを利用する事で、レジストリのトランザクションログファイルを反映したハイブファイルを作成できます。

f:id:hideakii:20180310080349p:plain

トランザクションログを反映した、SYSTEMハイブファイルを利用し、タイムラインを作成してみます。

トランザクションログを反映したSYSTEMハイブファイルは、002フォルダ配下に置いてあります。

Plaso(plaso-20180127)のLog2timelineを実行します。

f:id:hideakii:20180310080944p:plain

pinfoコマンドを利用し、エラーを確認します。チェックサムが一致しないようです。

> pinfo c:\case\Winreg_tl.db

f:id:hideakii:20180310081200p:plain

レジストリファイル内のチェックサムオフセット位置については、 「Windows registry file format specification」で位置を確認できます。

オフセット位置508を参照します。チェックサムが0x746B8159となっている事を確認できます。

f:id:hideakii:20180310081616p:plain

 チェックサムの値を、59から5Aに書き換えます。

f:id:hideakii:20180310082047p:plain

 チェックサムを書き換えたレジストリファイルに対して、Log2timeline を実行します。

f:id:hideakii:20180310082330p:plain

> pinfo c:\case\Winreg_tl2.db

f:id:hideakii:20180310082440p:plain

 エラー無く処理された事を確認できます。

psortコマンドを使いタイムラインを出力します。

f:id:hideakii:20180310082905p:plain

トランザクションログを反映した、レジストリのタイムラインを作成できました。

 

参考URL:

github.com

www.youtube.com

github.com

f:id:hideakii:20180310075939j:plain

Bam KeyとTransaction Log

  HKLM\SYSTEM\CurrentControlSet\Services\bam\ キーを引き続き確認します。
今回はレジストリのTransaction Logを、Registry Explorer/RECmd Version 1.0.0.0を使って参照したいと思います。

Live環境でのトランザクションログの取得には、RawCopyを利用します。
コピーのタイミングとしては、若干のズレが発生する可能性が考えられます。(BATファイルでコマンド実行しています。)

REM C:\Windows\System32\config\SYSTEM
RawCopy /FileNamePath:C:79240 /OutputPath:C:\Case

REM C:\Windows\System32\config\SYSTEM.LOG1
RawCopy /FileNamePath:C:79219 /OutputPath:C:\Case

REM C:\Windows\System32\config\SYSTEM.LOG2
RawCopy /FileNamePath:C:79218 /OutputPath:C:\Case

 もしかすると、VSSでスナップショットを作成してからファイルを確認する方が確実かもしれません。

サンプルのプログラムとしてfteを実行します。 

 

RawCopyでコピーしたSYSTEMハイブをRegistry Explorerで読み込みます。Dirtyハイブである事が検知されます。

f:id:hideakii:20180303100024p:plain

下記では、Dirtyハイブロードしました。

f:id:hideakii:20180303104921p:plain

まず、DirtyハイブでBAMキーと値を確認します。タイムスタンプが 2018-03-03 00:54:51 である事を確認できます。

f:id:hideakii:20180303104759p:plain

次に、トランザクションログ(LOG1)を反映したSYSTEMハイブでBAMキーと値を確認します。タイムスタンプが 2018-03-03 01:29:44 である事を確認できます。

f:id:hideakii:20180303105150p:plain

次に、トランザクションログ(LOG2)を反映したSYSTEMハイブでBAMキーと値を確認します。タイムスタンプが 2018-03-03 00:54:51 である事を確認できます。

f:id:hideakii:20180303105502p:plain

トランザクションログを適用する事で、最新の情報を確認できる事が分かります。

参考URL:

https://twitter.com/errno_fail/status/967831155310518272

https://twitter.com/EricRZimmerman/status/968897244232671234

http://ericzimmerman.github.io/

https://twitter.com/4n6k/status/968315227350749184

insights.arsenalexperts.com

https://www.linkedin.com/pulse/alternative-prefetch-bam-costas-katsavounidis

github.com

www.youtube.com

 

f:id:hideakii:20180303091549j:plain

bam key と Program execution

HKLM\SYSTEM\CurrentControlSet\Services\bam\ キーに記録される、プログラム実行の痕跡について検証された記事が下記で参照できます。

padawan-4n6.hatenablog.com

私もこのレジストリキーについて検証してみたいと思います。
テスト環境は Windows 10 ver 1709 です。
テスト開始時点における、レジストリキーは、下記の状況です。すでに、幾つかのプログラム実行に関連した値が登録されています。

f:id:hideakii:20180224074823p:plain

 

 プログラム実行のサンプルとして、APT Simulatorを実行します。RUN EVERY TESTを選択しています。

f:id:hideakii:20180224080138p:plain

f:id:hideakii:20180224080555p:plain

APT Simulatorの実行後、レジストリキーを確認します。PowerShellやWscriptなどの値が追加された事を確認できます。

f:id:hideakii:20180224081050p:plain

 システムを再起動します。 

再起動後、mim.exe と p.exe の値が新たに登録されている事を確認できます。これらは、UserInitMprLogonScriptとRunキーに登録されているプログラムです。

f:id:hideakii:20180224081419p:plain

値には、FILETIMEが含まれているようですが、更新タイミングの詳細については未確認です。再起動しなくても、タイムスタンプが変化しているような気もします。

シフトキーを5回押し、cmd.exeを起動した後のレジストリキーは下記になります。タイムスタンプがCMD.EXEを起動した日時に変化しています。

f:id:hideakii:20180224082856p:plain

 


タイムスタンプの更新については、id:kasasagi_fさんがテストされていますので、そちらも参照してください。 

 

参考URL:

padawan-4n6.hatenablog.com

Background Activity Moderator Driver - Windows 10 Service - batcmd.com

github.com

  

f:id:hideakii:20180224073746j:plain

USN Analytics と Folder

 Forensicistさんが、USN Analyticsツールを公開されています。USN Analytics ツールは、$J をパースするだけでなく、フォルダ構造も解析してくれます。

つまり、$MFT ファイルを利用せずに、フォルダ構造をある程度再現できます。

サンプルのフォルダ構造を、テスト用の NTFS ボリューム上に作成します。

E:\>mkdir folder1
E:\>cd folder1
E:\folder1>mkdir folder2
E:\folder1>copy c:\case\sample.jpg e:\folder1\folder2\

f:id:hideakii:20180210110855p:plain

USN Analytics で $J をパースした結果は下記になります。Path のカラムでフォルダ構造を確認できます。

f:id:hideakii:20180210111701p:plain

 次に、Folder1 を削除し、新規にファイルを作成します。新規ファイルを作成した事により、Folder1 の FILE レコードが上書きされます。

E:\>rmdir /S /Q folder1
E:\>echo sample > zaki.txt

sample.jpg ファイルは $OrphanFiles 配下で確認できます。

f:id:hideakii:20180210112332p:plain

USN Analytics の結果を確認します。Sample.jpg の Path から、Folder1 が過去に存在していた事を確認できます。

f:id:hideakii:20180210112814p:plain

 更にファイルを作成し、Folder2 と Sample.jpg の FILE レコードを上書きします。

E:\>echo sample2 > zaki2.txt
E:\>echo sample3 > zaki3.txt

$OrphanFiles 配下には痕跡が残っていません。

f:id:hideakii:20180210113854p:plain

USN Analytics の結果を確認します。これまでの操作状況が分かります。

f:id:hideakii:20180210114311p:plain

フォルダを作成し、USN Journal を削除します。

E:\>mkdir folder1
E:\>fsutil usn deletejournal /D E:

USN Journal を有効にし、フォルダとファイルを作成します。$J 内に、Folder1 を作成した記録はありません。

E:\>cd folder1
E:\folder1>mkdir folder2
E:\folder1>copy c:\case\sample.jpg folder2
E:\folder1>rmdir /S /Q folder2

USN Analytics の結果を確認します。Sample.jpg の Path は Folder2 から表示されています。Folder2 の Delete が無い?

f:id:hideakii:20180210135824p:plain

-r オプション指定し、再度プログラムを実行します。Folder2 の削除を確認できました。

f:id:hideakii:20180210140532p:plain

 素晴らしい!! 

 

参考URL;

USN Analytics | Forensicist

http://www.jpcert.or.jp/present/2018/JSAC2018_03_yamazaki.pdf

 

f:id:hideakii:20180210103911j:plain

 

Fixup と Update Sequence Number

NTFS の Fixup 値と update sequence について確認します。Fixup については NTFS Documentation を参照します。

 サンプルの画像ファイル coin.jpg を E: ドライブへコピーし、MFT ファイルでFile レコードを確認します。coin.jpg ファイルの File レコード番号は 39、シーケンス番号は 1 です。

f:id:hideakii:20180203100928p:plain

MFTファイル内のレコード番号39(1024 x 39 = 399,936 )を参照します。

下記 FILE レコードでは、オフセット位置 4 にある Offset to the update sequence 値が 30 00 (⇒ 48)となっています。

30 00 Offset to the update sequence ⇒ 48
03 00 Size in words of Update Sequence Number & Array (S) ⇒ 3

オフセット位置 48 からの 2 バイト、03 00 が update sequence になります。

f:id:hideakii:20180203101648p:plain

上記図では、セクタの終わりにある 00 00 が FixUp 値 03 00 と入れ替えられている状態です。

次に、coin.jpg ファイルの名前を変更しレコードをアップデートしてみます。

>ren e:\coin.jpg NotCoin.jpg

MFTファイル内のレコード番号39(1024 x 39 = 399,936 )を参照します。

レコードの更新により、update sequence04 00 となっている事を確認できます。

f:id:hideakii:20180203103620p:plain

次に、この JPEG ファイルを削除します。

>del e:\NotCoin.jpg

 MFTファイル内のレコード番号39 を参照します。
レコードの更新により、update sequence05 00 となっている事を確認できます。
また、ファイルが削除された事により、File レコードのシーケンス番号は 2 になった事を確認できます。

f:id:hideakii:20180203104150p:plain

 レコードを再利用してみます。

 >echo "Ancient Andes" > e:\gold.txt

  MFTファイル内のレコード番号39 を参照します。
レコードが再利用され、update sequence02 00 となっている事を確認できます。

f:id:hideakii:20180203105107p:plain

 

参考URL:

http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf

 

f:id:hideakii:20180203100509j:plain

 

$INDEX_ALLOCATION (0xA0)とVirtual Cluster Number (VCN)

Folderと$BITMAP (0xB0)」の続きです。

Windowsフォルダの $BITMAP (0xB0) は下記の状態です。VCN 0 から VCN 5 までが利用されている事を確認できます。

3F 00 00 00 00 00 00 00

0 0 1 1 1 1 1 1 ⇒ Bitmap ⇒ クラスタの利用状況

LCNとVCNの関係は下記となっています。これは、 ”Windows”フォルダの $INDEX_ALLOCATION (0xA0)と、VCN of this INDX buffer in the Index Allocation の内容から確認できます。

LCN 984 ⇒ VCN 0
LCN 985 ⇒ VCN 1
LCN 986 ⇒ VCN 2
LCN 987 ⇒ VCN 3
LCN 988 ⇒ VCN 4
LCN 989 ⇒ VCN 5

これらのクラスタが、どの様に繋がっているかを確認してみます。

 

$INDEX_ROOT (0x90)

まず$INDEX_ROOT (0x90)で利用しているVCNを確認します。Flags値から、Large indexが必要となっている事を確認できます。

Resident, Named
90 00 00 00 Attribute Type
58 00 00 00 Length (including this header)
00 Non-resident flag
04 Name length
18 00 Offset to the Name
00 00 Flags
06 00 Attribute Id (a)
38 00 00 00 Length of the Attribute
20 00 Offset to the Attribute (b)
00 Indexed flag
00 Padding
24 00 49 00 33 00 30 00 ⇒ $I30

Index Root
30 00 00 00 Attribute Type
01 00 00 00 Collation Rule
00 10 00 00 Size of Index Allocation Entry (bytes) ⇒ 4096
01 Clusters per Index Record ⇒ 1
00 00 00 Padding (Align to 8 bytes)

Index Header
10 00 00 00 Offset to first Index Entry ⇒ 16
28 00 00 00 Total size of the Index Entries ⇒ 40
28 00 00 00 Allocated size of the Index Entries ⇒ 40
01 Flags ⇒ Large index (Index Allocation needed)
00 00 00 Padding (align to 8 bytes)

Index Entry
00 00 00 00 00 00 00 00 File reference
18 00 Length of the index entry
00 00 Length of the stream
03 Flags ⇒ ??
00 00 00
05 00 00 00 00 00 00 00 VCN of the sub-node in the index allocation attribute

上記 Index Entry から、INDEX_ROOTからVCN 5 が参照されている事を確認できます。
次に、VCN 5の内容を確認してみます。

VCN 5(LCN 989)

VCN 5 (LCN 989)の Index Record を確認します。

Index Header

49 4E 44 58 Magic number 'INDX'
28 00 Offset to the Update Sequence
09 00 Size in words of the Update Sequence Number &Array (S)
9D 06 82 0C 00 00 00 00 $LogFile sequence number
05 00 00 00 00 00 00 00 VCN of this INDX buffer in the Index Allocation ⇒ 5
28 00 00 00 Offset to the Index Entries (a)
F8 01 00 00 Size of Index Entries (a) ⇒ 504
E8 0F 00 00 Allocated size of the Index Entries (a)
01 1 if not leaf node (b)
00 00 00 Padding (always zero)
02 00 Update sequence
00000000000000000000000000000000000000000000

Index Record 1

2407000000000100 MFT Reference of the file
7000 Size of this index entry
5200 Offset to the filename
0100 Index Flags
0000 Padding (align to 8 bytes)
3F05000000000100 MFT File Reference of the parent
C7FCC1272939D301 File creation time
C7FCC1272939D301 Last modification time
23629B61EB55D301 Last modification time for FILE record
C7FCC1272939D301 Last access time
0000000000000000 Allocated size of file
0000000000000000 Real size of file
0000001000000000 File Flags
08 Length of filename (F)
02 Filename namespace
44004900410047004E004F007E003100000000000000
00 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 0 ⇒ LCN 984

Index Record 2
snip
01 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 1 ⇒ LCN 985

Index Record 3
snip
02 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 2 ⇒ LCN 986

Index Record 4
snip
03 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 3 ⇒ LCN 987

Index Entry

00 00 00 00 00 00 02 00 File reference
18 00  Length of the index entry
00 00 Length of the stream
03 Flags ⇒ ??
00 00 00
04 00 00 00 00 00 00 00VCN 4 ⇒ LCN 988

 

まとめると、下記の繋がりとなります。

ROOT ⇒ VCN 5
VCN 5 ⇒ Index Records 1 ⇒ VCN 0
VCN 5 ⇒ Index Records 2 ⇒ VCN 1
VCN 5 ⇒ Index Records 3 ⇒ VCN 2
VCN 5 ⇒ Index Records 4 ⇒ VCN 3
VCN 5 ⇒ Index Entry ⇒ VCN 4

参考URL:

http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf

 

f:id:hideakii:20180121090355j:plain