ဖိုင်တွဲ အညွှန်းများ ($I30)¶
$I30 ဆိုသည်မှာ¶
NTFS ဖိုင်တွဲတိုင်းသည် ၎င်းအတွင်းရှိ ဖိုင်များ၏ index တစ်ခုကို $I30 အမည်ဖြင့် ထိန်းသိမ်းပါသည်။ ဖိုင်တွဲငယ်တစ်ခုသည်
၎င်းကို ၎င်း၏ $MFT record ($INDEX_ROOT) တွင် ထားပြီး ပိုကြီးသော ဖိုင်တွဲတွင် $INDEX_ALLOCATION:$I30 stream ၌
INDX record များ (များသောအားဖြင့် တစ်ခုလျှင် 4,096 byte) လည်း ရှိပါသည်။ Index entry တစ်ခုစီတွင် ဖိုင်၏ $FILE_NAME ၏
မိတ္တူ ပါဝင်ပါသည်။ ၎င်း၏ အမည်၊ MFT reference၊ parent ဖိုင်တွဲ၊ timestamp လေးခုနှင့် size နှစ်ခုကို NTFS က entry ကို
နောက်ဆုံး update လုပ်ခဲ့သည့် အချိန်အတိုင်း ဖြစ်ပါသည်။
ဖိုင်တစ်ခုကို ဖျက်လိုက်သည့်အခါ သို့မဟုတ် ဖိုင်တွဲမှ အမည်ပြောင်း၍ ရွှေ့ထုတ်လိုက်သည့်အခါ NTFS သည် ၎င်း၏ entry ကို
ဖယ်ရှားပြီး ၎င်းနောက်ရှိ entry များကို ရွှေ့ပါသည်။ ဟောင်းနေသော byte များသည် အသုံးပြုဆဲ entry များကို ကျော်လွန်၍
INDX record ၏ slack တွင် နောက်ပိုင်း entry များက ထပ်ရေးသည်အထိ ကျန်ရှိနေပါသည်။ Index slack သည် $MFT record ကို
ပြန်လည်အသုံးပြုပြီး USN Journal record များလည်း လည်ပတ်ပြီး ပျောက်သွားသော ဖိုင်တစ်ခု၏ အမည်၊ အချိန်များနှင့် size ကို
ထိန်းထားနိုင်ပါသည်။
အကောင်းဆုံး ကောက်ချက်: index slack တွင် တွေ့ရှိသော အမည်တစ်ခုသည် တစ်ချိန်ချိန်က
ဤဖိုင်တွဲ၏ index တွင် ဖော်ပြထားသော $FILE_NAME အချိန်များနှင့် size များဖြင့် ရှိခဲ့ပါသည်။ Slack entry တစ်ခုသည်
၎င်းကို မည်သည့်အချိန်တွင် ဖယ်ရှားခဲ့သည်၊ သို့မဟုတ် ဖျက်ခြင်း၊ အမည်ပြောင်းခြင်း သို့မဟုတ် rebalancing ကြောင့်
ရွှေ့ခြင်း ဖြစ်သည်ကို မဖော်ပြပါ။
တည်နေရာနှင့် စုဆောင်းခြင်း¶
$I30 သည် NTFS metadata ဖြစ်ပါသည်။ ဖိုင်တွဲတစ်ခု၏ $I30 stream ကို export လုပ်နိုင်သော raw-aware forensic tool
ဖြင့် စုဆောင်းပါ (export လုပ်ထားသော ဖိုင်များကို $I30 ဟု မကြာခဏ အမည်ပေးပါသည်)။ Juntei သည် disk image သို့မဟုတ်
unallocated space တွင် INDX record များကိုလည်း ရှာဖွေနိုင်ပါသည်။ Slack entry များသည် မည်သည့်အရာ ဖြစ်ခဲ့သည်ကို
သိရှိရန် တူညီသော volume ၏ $MFT နှင့် $J ကိုလည်း စုဆောင်းပါ။
စိစစ်သူများ သတိပြုရန်¶
- Index slack သည် မပြည့်စုံဘဲ အစီအစဉ်မရှိပါ။ ဖိုင်တွဲ ပြောင်းလဲလာသည်နှင့်အမျှ entry များ ထပ်ရေးခံရပါသည်။ အမည်တစ်ခု မရှိခြင်းက မည်သည့်အရာကိုမျှ မသက်သေပြပါ။
- Slack entry များစွာသည် entry များ ရွှေ့သည့်အခါ ကျန်ခဲ့သော အသုံးပြုဆဲ entry များ၏ မိတ္တူများ ဖြစ်ပါသည်။
CopyOfEntryInUseက ၎င်းတို့ကို အမှတ်အသားပြုပါသည်။ ဖျက်ထားသော အမည်တစ်ခုတည်းသည် slack တွင် အကြိမ်ကြိမ် ရှိနိုင်ပါသည်။ - Index entry ရှိ အချိန်များသည် entry ကို နောက်ဆုံး update လုပ်ခဲ့သည့်အချိန်က
$FILE_NAMEအချိန်များ ဖြစ်ပါသည်။ ၎င်းတို့သည် ဖိုင်၏$MFTrecord ၏$STANDARD_INFORMATIONနှင့်$FILE_NAMEအချိန်နှစ်မျိုးလုံးနှင့် ကွဲပြားနိုင်ပါသည်။ AllocatedSizeနှင့်RealSizeတို့သည်လည်း entry ၏ နောက်ဆုံး update အချိန်အတိုင်း ဖြစ်ပြီး ခေတ်မမီတော့နိုင်ပါ။- Slack entry ၏
FileEntry(သို့မဟုတ်ParentEntry) သည် နောက်ပိုင်း byte များက ထပ်ရေးသွားသည့်အခါ ပျောက်နေနိုင်ပါသည်။ ရှိနေသည့်အခါ ၎င်းဖော်ပြသော MFT record ကို ထိုအချိန်မှစ၍ ပြန်လည်အသုံးပြုထားနိုင်ပါသည်။ sequence number ကို နှိုင်းယှဉ်ပါ။ parse-ntfs i30သည် INDX record များကို ဖတ်ပါသည်။ ဖိုင်တွဲငယ်တစ်ခု၏ index သည် ၎င်း၏$MFTrecord ($INDEX_ROOT) တွင်သာ ရှိပြီး ၎င်း၏ ဖိုင်များကို$MFTတွင် တွေ့နိုင်ပါသည်။
Juntei ဖြင့် ခွဲခြမ်းစိတ်ဖြာခြင်း¶
Usage: juntei parse-ntfs i30 <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> Recursively find $I30 files (with $I30 in their name, or starting with an INDX record)
-f, --file <FILE> Parse one $I30 stream, or any file holding INDX records (a disk image, unallocated space)
Filtering:
--slack-only Only the entries found in slack
--no-copies Leave out the slack entries that copy an entry in use
Output:
-o, --output <FILE> Save every entry
-t, --output-type <TYPE> csv, json, or jsonl
juntei parse-ntfs i30 -f 'Users_$I30'
juntei parse-ntfs i30 -d evidence/ -o i30.csv
juntei parse-ntfs i30 -f 'Users_$I30' --slack-only --no-copies -t jsonl
juntei parse-ntfs i30 -f disk.raw -o carved-i30.csv
အနှစ်ချုပ်တွင် INDX record များ (နှင့် ၎င်းတို့ထဲမှ တစ်စိတ်တစ်ပိုင်းသာ ရေးထားသည့် အရေအတွက်)၊ အသုံးပြုဆဲနှင့် slack ရှိ entry များနှင့် အသုံးပြုဆဲ entry များ၏ တိကျသော မိတ္တူ မဟုတ်သည့် slack entry များ၏ အမည်များကို ဖော်ပြပါသည်။ ထိုအမည်များသည် ဖျက်ထားသော သို့မဟုတ် အမည်ပြောင်းထားသော ဖိုင်များအတွက် ဖြစ်နိုင်ခြေရှိသူများသာ ဖြစ်ပြီး ၎င်းတို့ချည်းသက်သက် ဆုံးဖြတ်ချက် မဟုတ်ပါ။
CSV ထုတ်ယူမှု field များ¶
| Field | အဓိပ္ပာယ်ဖော်ချက် |
|---|---|
SourcePath |
Input ဖိုင်။ host များနှင့် ဖိုင်တွဲများကို ခွဲခြားပါသည်။ |
RecordOffset, EntryOffset |
Input အတွင်းရှိ INDX record နှင့် entry ၏ byte offset များ။ မှန်ကန်မှု စစ်ဆေးခြင်းနှင့် disk image များတွင် တွေ့ရှိသော record များအတွက် မရှိမဖြစ် လိုအပ်ပါသည်။ |
RecordVCN, RecordLSN |
Index stream အတွင်း record ၏ နေရာနှင့် ၎င်း၏ $LogFile sequence number။ |
FromSlack |
အသုံးပြုဆဲ entry များကို ကျော်လွန်၍ တွေ့ရှိသော entry အတွက် True။ |
CopyOfEntryInUse |
တူညီသော ဖိုင်တွဲ index ၏ အသုံးပြုဆဲ entry တစ်ခုနှင့် အမည်၊ namespace၊ ဖိုင် (သိရှိလျှင်)၊ parent နှင့် အချိန်များ တူညီသော slack entry။ များသောအားဖြင့် entry များ ရွှေ့ရာမှ ကျန်ခဲ့သော အကြွင်းဖြစ်ပြီး ဖျက်ထားသော ဖိုင် မဟုတ်ပါ။ |
Filename |
ဖိုင်တွဲအတွင်းရှိ အမည်။ |
Namespace |
win32, dos (8.3 short name), win32_and_dos, သို့မဟုတ် posix။ |
FileEntry, FileSequence |
ဖိုင်၏ MFT reference။ header ကို ထပ်ရေးခံရသော slack entry အတွက် ဗလာ ဖြစ်ပါသည်။ |
ParentEntry, ParentSequence |
ဖိုင်တွဲ၏ MFT reference။ အခြား byte များက ထပ်ရေးသွားသည့်အခါ ဗလာ ဖြစ်ပါသည်။ |
CreatedUTC, ModifiedUTC, MFT-ModifiedUTC, AccessedUTC |
Entry ၏ နောက်ဆုံး update အချိန်အတိုင်း 100 ns အထိ တိကျသော $FILE_NAME အချိန်များ။ |
AllocatedSize, RealSize |
NTFS က entry ထဲသို့ ကူးထည့်ခဲ့သော size များ။ အထက်ပါ သတိပြုရန်အချက်များကို ကြည့်ပါ။ |
FileAttributes |
| ဖြင့် ဆက်ထားသော attribute အမည်များ (hidden|archive)။ subdirectory အတွက် is_directory။ ဤ Juntei ဗားရှင်းက အမည်မပေးသော bit များကို hexadecimal (0x00800000) ဖြင့် ထိန်းထားပါသည်။ |
ReparseValue |
$FILE_NAME မှ reparse tag သို့မဟုတ် extended-attribute size။ |
Problems |
တစ်စိတ်တစ်ပိုင်းသာ ရေးထားသော sector များကဲ့သို့ record အတွင်းရှိ ပျက်စီးမှု။ ပျက်စီးနေသော record မှ entry များကိုလည်း သတိထား၍ ပြန်လည်စစ်ဆေးသင့်ပါသည်။ |
JSON/JSONL တွင် snake_case ဖြင့် တူညီသော field များ ပါဝင်ပြီး problems ကို list အဖြစ်နှင့် မသိရှိသော
တန်ဖိုးများအတွက် null ကို အသုံးပြုပါသည်။
Slack entry များကို ရှာဖွေပုံ¶
Slack ကို entry များ စတင်သည့် 8-byte နယ်နိမိတ်တိုင်းတွင် entry အပြည့်အစုံများ၊ entry header ကို ထပ်ရေးခံထားရသော
$FILE_NAME attribute များနှင့် slack ၏ အစတွင် အသုံးပြုဆဲ entry များ၏ အဆုံးပိုင်းက parent reference ကို ထပ်ရေးသွားသော
$FILE_NAME ကို scan လုပ်ပါသည်။ ဖြစ်နိုင်ခြေရှိသူ တစ်ခုသည် Windows ရေးသားသည့်ပုံစံနှင့် တူရပါမည်။ control character
သို့မဟုတ် path ခွဲခြားသင်္ကေတ မပါသော မှန်ကန်သည့် UTF-16 အမည်၊ 1980 မှ 2100 ကြားရှိ အချိန်လေးခု၊ သိရှိထားသော
namespace နှင့် သိရှိထားသော attribute flag များ ဖြစ်ပါသည်။ 32 bit ကျော်သော parent reference သည် ၎င်းကို ထပ်ရေးသွားသော
byte များ ဖြစ်သောကြောင့် ဗလာထားပါသည်။
Record တစ်ခုစီ၏ update sequence array ကို အသုံးချပါသည်။ update sequence တန်ဖိုးဖြင့် မဆုံးသော sector သည်
တစ်စိတ်တစ်ပိုင်းသာ ရေးထားခြင်း ဖြစ်ပါသည်။ Juntei သည် record ကို ရှိသည့်အတိုင်း ဖတ်ပြီး ထို sector များကို
Problems တွင် ဖော်ပြပါသည်။
စုံစမ်းစစ်ဆေးမှု ဗျူဟာ¶
- အနှစ်ချုပ်ရှိ slack အတွင်းမှ မိတ္တူမဟုတ်သော အမည်များဖြင့် စတင်ပြီး နောက်တွင်
--slack-only --no-copiesဖြင့် စစ်ထုတ်ပါ။ FileEntryကို$MFTတွင် ရှာပါ။FileSequenceတူညီလျှင် ဖိုင်တူ ဖြစ်ပြီး ပိုမြင့်လျှင် record ကို ထိုအချိန်မှစ၍ လွှတ်ပေးခဲ့ပြီး ပြန်လည်အသုံးပြုထားနိုင်ပါသည်။- ဖျက်ခြင်း သို့မဟုတ် အမည်ပြောင်းခြင်း ဖြစ်ခဲ့သည့်အချိန်ကို သိရှိရန် USN ဂျာနယ် တွင် အမည်ကို ရှာပါ။
- Timestomping အတွက်
$FILE_NAMEအချိန်များကို$MFT၏$STANDARD_INFORMATIONအချိန်များနှင့် နှိုင်းယှဉ်ပါ။ - ဖိုင်ကို မည်သို့ အသုံးပြုခဲ့သည်ကို သိရှိရန် Prefetch၊ LNK၊ Jump Lists နှင့် event log များနှင့် ဆက်စပ်စစ်ဆေးပါ။
နောက်ထပ် အသေးစိတ်များ¶
- Microsoft: Master File Table
- libfsntfs: NTFS ဖိုင်ပုံစံ စာတမ်း
- dfir_ntfs
- INDXRipper
- ys-ntfs-parser (၎င်း၏
mftcrate ၏i30module)