快速格式化後的 NTFS 元資料：WinHex 分析
快速格式化後的 NTFS 元資料描述的是新初始化的檔案系統，但前一個檔案系統中的某些記錄和檔案內容，可能仍可在其底層被讀取。Windows 會建立新的主檔案表（Master File Table）和目錄結構；它並非單純將所有舊檔案名稱隱藏起來。當足夠多的原始元資料及其所描述的資料得以保留且仍可存取時，資料恢復便會成功。.
WinHex 透過顯示開機區段欄位、MFT 記錄以及資料區映射，協助區分這些情況。本文探討一個 NTFS 轉 NTFS 的快速格式化案例，以及另一個 MFT 碎片重建範例。 這些計算結果僅適用於記錄的佈局，而非所有 Windows 磁碟區。SSD 的棄用行為及隨後的寫入操作可能會產生截然不同的結果。.
目錄
1. NTFS 中的「快速格式化」有哪些變更？
的 NTFS 檔案系統 透過元資料檔案、目錄索引及叢集映射來組織檔案。快速格式化會建立這些結構的新實例。.
結構 | 快速格式化後的角色 | 對復原的影響 |
磁碟區開機區及其備份 | 請描述此新格式化的磁碟區 | 當前的 MFT 指標可能無法再定位到舊的表 |
$MFT 與根目錄 | 請描述新的檔案系統及其初始物件 | 在正常瀏覽時，舊的檔案名稱和目錄關聯性會消失 |
| 追蹤新 MFT 中已分配的記錄 | 不會將該表格以外的現存紀錄納入清點範圍 |
$位圖 | 追蹤分配至新卷中的叢集 | 先前已被佔用的叢集可重新釋出以供重複使用 |
$MFTMirr 及其他系統元資料 | 支援新初始化的檔案系統 | 他們的寫入操作可能會覆寫較舊的元資料或檔案內容 |
檔案資料的舊位置 | 可能在被覆寫或捨棄的範圍之外保留可讀內容 | 生存能力必須加以確認，而非理所當然地假設 |
的 主檔案表 它本身就是一個檔案。其未命名的 $DATA 資料流包含檔案記錄；其位圖則描述了記錄的分配情況。獨立的 $Bitmap 檔案則描述了整個卷上的叢集分配情況。若將這兩個位圖混淆，將會導致對哪些資料得以保留的錯誤判斷。.
格式化現有分割區與刪除其分割區表條目亦有所不同。執行「卷宗格式化」程序會重建所選卷宗內的檔案系統；而刪除分割區則涉及卷宗外部的磁碟佈局。.
2. 在 WinHex 中讀取原始開機扇區
若要對 NTFS 格式化前後進行十六進位比對，請在格式化前保存一個磁區映像檔，並將其與格式化後擷取的映像檔進行比對。若來源磁碟已格式化，則應以現有的映像檔及任何可取得的較早擷取資料為依據進行分析。請勿重複執行格式化以重現該事件。.
的 磁碟區開機記錄 提供了解讀叢集位址所需的參數。.
摘自 WinHex 案件記錄中的原始開機扇區十六進位片段。紅色方框標示了扇區大小、簇大小及 MFT 位置欄位。.
開機區段偏移量 | 記錄的位元組 | 口譯 |
|
| 每個邏輯扇區 512 位元組 |
|
| 每個叢集包含八個區段 |
|
| $MFT 從 LCN 175,724,968 開始 |
|
| $MFTMirr 從 LCN 167,336,228 開始 |
|
| 有符號數值 −10：記錄大小為 2¹⁰ = 1,024 位元組 |
多位元組整數採用小端字節序。該 分配單位大小 因此是：
- 每個叢集為 512 × 8 = 4,096 位元組
LCN 指的是相對於卷的叢集編號。因此：
- 原始 MFT 體積相對扇區 = 175,724,968 × 8
- = 1,405,799,744
- 原始 MFT 相對於卷的位元組偏移量 = 175,724,968 × 4,096
- = 719,769,468,928
檢視整個磁碟映像時，請加上該磁區的起始位元組偏移量；檢視僅包含單一磁區的映像時，則無需再次加上此偏移量。WinHex 顯示的位址上下文必須與計算結果相符。.
開機區段會標示第一個 MFT 區段。它並不會描述該表中的每個碎片。.
3. 解碼原始 MFT 的非常駐資料
在原始的 MFT 位置，驗證記錄 0，並找出其未命名的 $DATA 屬性，輸入 0x80. 非駐留屬性僅在記錄中儲存映射資訊，而非其完整內容。.
案例筆記將此屬性置於記錄偏移量處 0x100. 這使得其形式位元組出現在 0x108; 該值 01 意指「非居民」。這些絕對偏移量屬於此記錄。其他記錄可將該屬性置於其他位置。.
在解讀另一筆記錄時，請使用相對於該屬性起始位置的偏移量：
相對偏移量 | 現場 |
| 居民／非居民表格 |
| 最低虛擬叢集編號（VCN） |
| 最高 VCN，含該值 |
| 映射對陣列的偏移量 |
| 分配長度 |
| 邏輯檔案大小 |
| 有效資料長度 |
請分別解讀這三個大小欄位。已分配長度用於預留儲存空間，邏輯大小定義資料流長度，而有效資料長度則描述已初始化的資料。這三者不一定要相等。.
在涵蓋 VCN 0 至 98,431 的範圍內，叢集數量為 98,432，而非 98,431。記錄中的兩次運行佈局結果如下：
運行 | 叢集數量 | 簽署的 LCN delta | 啟動 LCN | 每個邏輯記錄槽為 1,024 位元組 |
1 | 75,096 | +175,724,968 | 175,724,968 | 0–300,383 |
2 | 23,336 | +83,118,309 | 258,843,277 | 300,384–393,727 |
第二個位址是相對於前一次執行所產生的 開始 LCN：
- 175,724,968 + 83,118,309 = 258,843,277
- (75,096 + 23,336) × 4,096 = 403,177,472 位元組
- 403,177,472 ÷ 1,024 = 393,728 筆記錄槽位
這些是可尋址的槽位，而非有效檔案的數量。部分記錄可能未被使用，且一個檔案可能需要多個記錄。.
已記錄的運行標題 43 和 42 說明欄位寬度。對於 43, ，長度佔用三個位元組，而 LCN 差值佔用四個位元組；對於 42, ，長度佔用兩個位元組，而差值佔用四個位元組。請將 LCN 差值視為有符號數，因為後面的片段可能位於卷的較早位置。.
所得的範圍長度為 384.5 MiB。將數值四捨五入顯示為「385 MB」，並不能單憑此點就斷定分配大小不同，亦無法證明已預留了額外的簇。.
4. 比較新版 MFT 與舊版佈局
案例筆記中記載了一個起始於 LCN 786,432、範圍為 180 個簇的後格式 MFT。假設記錄的簇大小為 4,096 位元組：
- 新 MFT 的起始位元組偏移量 = 786,432 × 4,096
- = 3,221,225,472
- 新範圍大小 = 180 × 4,096 = 737,280 位元組
新的起始位置位於卷的第 3 GiB 處。該位址是根據此案例觀察所得，並非 NTFS 的強制位置。.
屬性 | 原始版面配置 | 在筆記中記錄的貼文格式佈局 |
啟動 MFT LCN | 175,724,968 | 786,432 |
已記錄的 MFT 區段 | 二 | 一 |
承保範圍 | 98,432 個聚類 | 180 個叢集 |
在記錄的記錄大小下的容量 | 393,728 個槽位 | 720 個插槽 |
註釋中亦提及記錄 0–717。這共計 718 筆記錄，即 735,232 位元組。此數值與足以容納 720 個槽位的記憶體分配相符，但無法確定 718 所指的是邏輯長度、初始化長度，還是已檢查的記錄數。 這些欄位需要底層的屬性位元組。.
一項重要的變更在於，Windows 現已採用新的表格。新 MFT 的體積較小，這使得 不是 這意味著舊資料表已在原處進行了實體截斷。其原先的位置必須另行檢查。.
要判斷 NTFS MFT 是否因格式化而被覆寫，請將原始 MFT 區段與所有新寫入的元資料及後續的分配進行比對。若指標發生變更，即證明參考關係已改變；透過位元組比對，則可確認特定位置是否遭到覆寫。僅憑位置變更，既無法證明資料完全存留，也無法證明資料完全遺失。.
5. 根據現存紀錄重建已碎裂的 MFT
隨著資料表不斷擴充，且連續的空間逐漸耗盡，MFT 碎片化便會逐漸產生。NTFS 會預留一個 MFT 區塊以減少碎片化，但這並不能保證僅形成單一延伸區。資料表擴充時，碎片可能會被分配在當前延伸區的前方或後方。.
本案例資料中另有一個獨立的重建範例，記錄了此三行佈局。切勿將其與前面的兩行佈局案例混為一談，彷彿兩者描述的是同一張表格。.
運行 | 邏輯記錄槽 | 啟動 LCN | 與前次執行開始時的差異 | 群集 |
1 | 0–204,927 | 786,432 | +786,432 | 51,232 |
2 | 204,928–248,587 | 9,274,281 | +8,487,849 | 10,915 |
3 | 248,588–376,391 | 8,858,108 | −416,173 | 31,951 |
每個 4,096 位元組的叢集可容納四個 1,024 位元組的槽位。這解釋了這兩項邊界：
- 51,232 × 4 = 204,928 個插槽
- 204,928 + (10,915 × 4) = 248,588
- 9,274,281 − 416,173 = 8,858,108
這些執行結果合計涵蓋 94,098 個叢集，即 385,425,408 位元組。最終的 VCN 為 94,097。.
查找並驗證候選人記錄
重建筆記中記載了搜尋第 204,928 筆紀錄的過程，其中有一筆候選紀錄因無效而被排除，並找到另一筆被認定為有效的候選紀錄。相符的編號或該 檔案 僅有簽名是不夠的。.
在唯讀映像檔上：
- 搜尋
檔案簽名，包括位於當前 MFT 之外的位置。若僅掃描新資料表，將會遺漏已脫離的記錄。. - 檢查記錄邊界、記錄長度、屬性偏移量及屬性長度。.
- 在解析受保護的記錄位元組之前，請先驗證更新序列陣列。在記錄的 1,024 位元組記錄中，其檢查範圍涵蓋兩個 512 位元組步長區段的末端。.
- 在跨過這些邊界解析屬性之前，請先將已儲存的預告片字詞還原至解析器的記憶體中；請勿修補證據影像。.
- 比較相鄰的記錄、現有的記錄編號、名稱、父記錄參考及序列號。剔除不合理或過時的關聯關係。.
若尚存的舊記錄 0 提供了有效的執行清單，則應採用該映射。若該記錄缺失，則從記錄序列重建延伸區仍僅為一種假設，需進行額外檢查。區域內的空白記錄本身並不能證明不存在後續的片段。.
分別重新組建邏輯表
將已驗證的範圍依 VCN 順序複製到另一個分析檔案中。請勿按 LCN 遞增順序進行排序：上述第三次執行結果在磁碟上位於第二次之前，但在邏輯上卻緊接在第二次之後。.
關於紀錄編號 n, 記錄大小 R, ，以及叢集大小 C:
- VCN = floor(n × R ÷ C)
- 叢集內的偏移量 = (n × R) mod C
- LCN = 該次運行起始 LCN + (VCN − 該次運行起始 VCN)
以三輪執行範例中的第 204,929 筆記錄為例，其 VCN 為 51,232，叢集內偏移量為 1,024 位元組。因此，其卷宗相對位址為：
- 9,274,281 × 4,096 + 1,024 = 37,987,456,000 位元組
此映射僅能找回一個位址，而非檔案。該記錄及其所引用的資料仍需進行驗證。.
6. 透過舊屬性恢復檔案內容
一旦理解了某個存留的檔案記錄，其 $DATA 屬性便會決定資料擷取的方法。.
居民資料： 讀取屬性的值偏移量和長度，然後從經過驗證且經修復還原的記錄中匯出該值。由於小檔案的內容儲存於 MFT 記錄中，因此當其 MFT 記錄被覆寫時，這些檔案的內容可能會遺失。.
一般非居民資料： 解碼檔案本身的執行清單、從原始卷映像中讀取每個區段、將位元組依 VCN 順序組裝，並將輸出裁切至邏輯檔案大小。MFT 執行清單用於定位檔案記錄；它並不能取代每位使用者自身的檔案-資料對應關係。.
當屬性延伸至其他記錄時，請遵循 $ATTRIBUTE_LIST 的參照規則。稀疏與壓縮資料流需分別遵循其對應的解碼規則。加密內容仍需使用適用的解密素材。在這些情況下，單純的串接並不足夠。.
目錄復原需要格外謹慎。即使其父目錄已不存在，檔案名稱仍可能保留下來。僅在參照與序號相符的情況下才重建路徑；否則，應保留孤立檔案，而非虛構資料夾間的關聯。.
將提取的檔案儲存至另一個實體裝置。編輯新的開機區塊使其指向舊的 MFT，並不等同於恢復檔案：分配映射、索引、系統記錄及其他元資料可能屬於不同的檔案系統實例。.
7. 為何復原能成功——以及為何會失敗
基於元資料的復原之所以能成功，是因為舊記錄會保留檔案的識別碼、邏輯大小及資料映射關係，而映射的內容仍可讀取。即使 Windows 已不再將這些資訊納入其活躍命名空間中，復原工具仍能循著這些關聯進行復原。.
若記錄遺失，基於簽名的資料提取技術有時可直接識別檔案內容。此方法通常會遺失原始檔案名稱與目錄結構，且對於碎片化的檔案而言可靠性較低。X-Ways 將搜尋當前 MFT 以外的 NTFS 記錄與搜尋檔案標頭區分開來，這反映了這兩種不同的資料恢復方法。.
當新的元資料與原始記錄重疊、後續檔案重複使用舊的簇，或是碎片映射資訊遺失時，資料復原的難度便會增加。有效的檔案名稱並不能證明內容完整無缺；可辨識的第一頁或影片標頭，也無法證明後續的碎片仍完整保存。.
SSD 還有一項額外條件。Windows 格式化時會發送 TRIM／刪除通知；微軟的 格式 文件包含 /NoTrim 以壓制這些資料。這是一項格式化選項，而非資料遺失後的補救措施。視裝置及儲存路徑而定，即使在 WinHex 中未可見傳統的覆寫痕跡，被捨棄的區段也可能不再返回原始位元組。因此，快速格式化並不能保證資料必定可恢復。.
8. 在重新使用磁碟之前，請先驗證已擷取的資料
請將原始影像和範圍圖保留至驗證完成為止。有關實用的掃描與匯出工作流程，請參閱 從已格式化的硬碟中恢復檔案.
如有可用，請將恢復的檔案與格式化前的清單進行比對。比較檔案名稱、大小、資料夾關係及雜湊值與已知的原始檔案。若無基準雜湊值，請開啟文件並檢視其頁面、測試壓縮檔、以全解析度檢視圖片，以及播放完整的影片檔案。.
請將受損或遺失的檔案與已驗證的檔案分開記錄。若重建的 MFT 沒有解析錯誤，即表示元資料可讀；若匯出的內容可正常使用，則表示檔案已成功恢復。要實現完全恢復，必須將預期資料集納入考量。.
常見問題
快速格式化會覆寫整個 NTFS MFT 嗎？
當檔案的 MFT 記錄消失時，檔案還能存活嗎？
MFT 鏡像能否還原每筆檔案記錄？
新卷位圖中的零位是否表示舊資料已被刪除？
舊的 MFT 記錄是否仍可能處於「正在使用中」狀態？
還原舊的開機區段是否能撤銷格式化？
