MBR 分割區刪除測試：WinHex 中的刪除前後對比
這個 MBR 分割區刪除測試 說明了為何一個遺失的分區會變成未分配狀態，而其 NTFS 開機扇區卻仍可讀取。在記錄的案例中，刪除中間的分區會將其對應關係從 MBR 表中移除。 緊接其後的分區佔用了表中的第二個槽位，而第三個槽位則為空。後來重建該條目後，E: 磁碟機便再次可見，後續檢查也證實恢復的資料完整無缺。.
本案例涉及一個採用 512 位元組邏輯扇區、基本 MBR 資料磁碟上的主要 NTFS 分割區。文中說明了 WinHex 記錄的變更及其後果。關於底層結構，請參閱 MBR 分區表指南.
目錄
測試磁碟與證據
歷史測試記錄顯示，在 Windows 磁碟管理中，有一個標示為「磁碟 1」的獨立磁碟。磁碟編號和磁碟機代號僅用於識別此情況；它們並非用於選擇另一台電腦的磁碟的指示。.
項目 | 記錄狀態 |
測試磁碟 | 基本 MBR 磁碟，顯示為 2.00 GB |
初始數量 | D：1.00 GB；E：500 MB；F：521 MB，如「磁碟管理」所顯示 |
檔案系統 | 這三個磁區皆採用 NTFS 檔案系統 |
已刪除的物件 | 中間主要分割區，原為 E: |
檢驗工具 | Windows 磁碟管理與 WinHex |
邏輯扇區大小 | 512 位元組，亦可編碼為 |
測試結果 | E：以 499 MB 的 NTFS 主要分割區形式重新出現；後續檢查確認已恢復的資料完整無缺 |
這些螢幕截圖記錄了刪除前的佈局、刪除後未分配的區域、殘存的開機區段資訊，以及重建過程。至於 Windows 版本、WinHex 版本、底層 HDD/SSD/虛擬磁碟類型，以及測試日期，則未予記錄。.
沒有儲存刪除前 LBA 0 的轉儲檔。因此，這是一項案例分析，而非完整的逐位元組刪除稽核。無法將原始條目的確切位元組作為測量基準呈現。.
MBR 分區表有哪些變更？
MBR 位於磁碟的 LBA 0 處。其分割區表佔用的偏移量為 0x1BE–0x1FD, ，包含四個 16 位元組的記錄。簽名位元組 55 AA 佔領 0x1FE–0x1FF.
每個記錄包含分區類型、起始 LBA 以及扇區數。這些資訊描述了磁碟的某個區域；其中並不包含該區域內的資料夾或檔案內容。.
以下分區佔用了插槽 2
WinHex 的刪除後螢幕截圖中包含以下這兩筆已佔用的記錄：
MBR 欄位 | 插槽 1，與 D 相關聯： | 插槽 2，與 F 相關聯： |
記錄開始 |
|
|
類型 |
|
|
起始 LBA 位元組 |
|
|
起始 LBA，十進位 | 128 | 3,121,280 |
磁區計數位元組 |
|
|
扇區數，十進位 | 2,097,152 | 1,067,008 |
第 3 和第 4 個槽位被零填充。缺失的中間卷沒有任何記錄描述其起始位置和大小。.
因此，記錄的序列支持對存留記錄進行壓縮：移除中間分區後，F: 佔據第 2 個槽位。. 刪除第二個分割區，並不一定會使第二個槽位保持空置。. 其他工具可能會清除某筆記錄，但不會重新排列剩餘的條目。.
刪除後的 LBA 0：殘留的項目描述了 D: 和 F:。第三和第四筆記錄為空，且存在 MBR 簽名。.
WinHex 還會列出一個沒有磁碟機代號的中間 NTFS 區域。其分割區清單可能包含除目前在 MBR 中註冊之外的已偵測檔案系統。原始記錄可確定該表格實際包含的內容；僅憑偵測到的 NTFS 區域，並不能證明 Windows 已將其掛載。.
正確解讀位元組
MBR 的多位元組位址欄位採用小端序。例如：
- 80 A0 2F 00 -> 0x002FA080 -> LBA 3,121,280
這些是邏輯磁區位址。該 邏輯區塊位址指南 說明了區塊大小與位址來源如何影響其解讀。.
為什麼 E: 會變成未分配空間？
Windows 通常會使用分割區記錄來識別包含磁碟區的磁碟區域。一旦中間區域沒有有效的對應關係，便無法再透過一般檔案存取方式將其作為原始的 E: 磁碟區使用。.
這就解釋了為何會出現那條黑色的「未分配」區段。這並不表示該區域中的每個磁區都包含零。.
刪除分割區與刪除其中的個別檔案也有所不同。刪除檔案會變更檔案系統記錄；而刪除分割區則會變更磁碟佈局，而作業系統正是透過此佈局來存取該檔案系統。該 NTFS 主檔案表 將檔案記錄儲存於磁區內；它與四個 MBR 分割區記錄是分開的。.
這些螢幕截圖顯示了殘存的開機元資料。若未進行完整的磁碟比對，這些截圖並不能證明每隔一個磁區都未被修改。此外，由於無法取得原始的 LBA 0 轉儲資料，這些截圖也無法證實開機程式碼或磁碟簽名位元組是否未被修改。.
尋找已刪除分割區的 NTFS 開機區
現存的第一份分區文件提供了一個有用的起始假說：
- D：起始 LBA = 128
- D：分割區長度 = 2,097,152 個扇區
- D: 之後的第一個 LBA 為 2,097,280
- 以 512 位元組 LBA 計算的位元組偏移量 = 2,097,280 × 512
- = 1,073,807,360
- = 0x40010000
原始記錄還顯示，D: 磁碟的備用開機區段位於 LBA 2,097,279，即緊接在該位址之前。鄰近的分區未必會緊接在該位址之後開始，因此此計算結果僅能作為候選選項，而非放諸四海皆準的規則。.
在 LBA 2,097,280 處，WinHex 顯示了一個 NTFS 開機區，其中包含幾個相互一致的欄位：
開機區段偏移量 | 記錄的位元組 | 口譯 |
|
| 此 NTFS 磁區中的開機程式碼跳轉指令 |
|
| OEM 識別碼 |
|
| 每扇區 512 位元組 |
|
| 隱藏區塊欄位：2,097,280 |
|
| NTFS 磁區計數欄位：1,021,951 |
|
| 開機區結尾標記 |
此表中的偏移量是以 NTFS 開機扇區為基準，而非 LBA 0。.
原始的 WinHex 擷取畫面顯示，疑似 NTFS 啟動區位於 LBA 2,097,280 處。其位置與「隱藏區塊」欄位的資料相符。.
位於 0x1C 是 並非 NTFS 預留區段欄位. 若將這些欄位混淆，將會導致分區起始位置識別錯誤。同樣地，搜尋 EB 52 90 僅憑此尚不足夠：過時的開機區複本以及無關的匹配位元組，都可能產生誤導性的匹配結果。請一併確認檔案系統識別碼、磁區大小、邊界以及可存取的元資料。.
重構入境經過：紀錄所顯示的內容
該記錄的重建過程首先保留了 F：，方法是將其記錄複製到槽位 3。接著，它為缺失的 NTFS 區域填補了槽位 2。.
錄製的第 2 槽包含：
現場 | 記錄值 |
開機指示燈 |
|
分割區類型 |
|
起始 LBA 位元組 |
|
磁區計數位元組 |
|
這份 MBR 分區表的「前後」對比，區分了觀察到的狀態與無法取得的原始位元組：
州 | 視窗佈局或顯示效果 | MBR 證據 |
刪除前 | 在「磁碟管理」中可見 D:、E: 和 F: | 原始 LBA 0 位元組未擷取 |
刪除後 | 中間區域 未分配 | 插槽 1：D:；插槽 2：F:；插槽 3–4：空 |
重建 | E：隨後再次出現 | 插槽 1：D:；插槽 2：重建的 NTFS 記錄；插槽 3：保留的 F: |
第一行描述原始的可見佈局；它並未逐位元組地確立原始的槽順序。.
重建擷取結果顯示起始位元組 80 00 20 00 以及長度位元組 FF 97 0F 00. 這些是記錄下的數值，並非通用的恢復參數。.
為何長度需要額外檢查
MBR 記錄需要完整的分區長度。NTFS 開機扇區計數不應自動複製到該欄位中。.
前面的 D: 磁碟區可在同一筆記錄內進行交叉核對：其 MBR 長度為 2,097,152 個磁區，而其備份的 NTFS 開機磁區則包含 FF FF 1F 00 00 00 00 00, ，或 2,097,151。.
就 Linux NTFS 實作中記載的 NTFS 結構而言，開機扇區的數量比包含備用開機扇區在內的總範圍少一個。將此關係套用至此候選方案，結果為：
- 記錄的 NTFS 計數 = 1,021,951
- 候選完整跨度 = 1,021,952 個扇區
- 候選備用 LBA = 2,097,280 + 1,021,951
- = 3,119,231
候選跨度將編碼為 00 98 0F 00, ，而非記錄中的 FF 97 0F 00. 後者指的是在早一個扇區處結束的分區。.
這是一項邊界計算，並非經過驗證的替代值。在寫入任何資料之前，請先確認實際的備份磁區以及原始分割區的範圍。 原始分割區也可能包含超出 NTFS 磁區範圍的尾部空位。F: 從 LBA 3,121,280 開始，在候選的完整 NTFS 範圍之後還剩 2,048 個磁區；該間隙絕不能自動併入還原後的磁區中。.
MBR 刪除恢復測試是否成功？
測試成功：重建 MBR 條目後，已恢復對 E: 磁碟機的存取權限，後續檢查亦確認已恢復的資料完整無缺。最後的「磁碟管理」螢幕截圖顯示，該分割區已被識別為 NTFS 格式，且狀態為「正常（主要分割區）」。.
重建後，E: 會顯示為一個 499 MB 的 NTFS 主要分割區。.
最初的螢幕截圖顯示為 500 MB；最後一張則顯示為 499 MB。這項差異，加上磁區數的問題，使得無法斷言已精確還原原始的邊界。僅憑顯示的容量，無法彌補原始磁區數的缺失。完整的資料復原與精確還原原始分割區範圍，是兩項不同的結論。.
重建完成後，已對恢復的分區中的資料進行檢查，並確認資料完整無缺。. 因此，這項測試不僅證實了分區存取功能已恢復，也證實了資料已完全恢復。. 此結果僅適用於此特定測試；在其他磁碟上能否恢復資料，則取決於其檔案系統的元資料與檔案內容是否仍保持完整。.
在重複進行此實驗時，請驗證已恢復的檔案以及分割區結構：
- 其邊界包含已驗證的檔案系統範圍，且不會與其他分割區重疊。.
- 主開機區段與備用開機區段的位置均符合建議的佈局。.
- 可以讀取目錄和預期的檔案名稱。.
- 重要檔案可以複製到另一顆磁碟，並在對應的應用程式中開啟。.
- 若有原始基準值，請將檔案大小與之進行比對。若存在刪除前的雜湊值，請將其作為額外的完整性檢查進行比對。.
何時可以恢復該分割區及其檔案？
一項關於已刪除 MBR 分區條目的實驗，說明了為何結構性復原能夠奏效：儘管映射關係可能消失，但只要檔案系統有足夠的部分存留下來，便能再次識別該分區。.
復原路徑取決於剩餘的內容：
狀況 | 實際意義 |
一致的開機區段、可讀取的 NTFS 元資料、已知的邊界 | 重建分割區可能會恢復存取權限 |
邊界不明確，但檔案元資料仍可讀取 | 在變更資料表之前，請先將檔案備份至另一顆磁碟 |
被覆寫的檔案內容 | 重新建立該條目無法還原被覆寫的位元組 |
沒有所需金鑰的加密資料 | 還原分割區地圖並不會解密內容 |
讀取錯誤或硬體不穩定 | Prioritize suitable imaging or specialist assessment |
Partition reconstruction writes disk-layout information. File recovery extracts surviving files to another destination. Boot repair addresses startup structures. These operations solve different problems.
For an actual missing drive, follow the lost partition recovery guide. Avoid creating or formatting a replacement volume over the missing region before protecting its files.
How to Inspect the Same Evidence Safely in WinHex
Use a disk image or disposable test disk for experiments. Preserve an untouched copy before any reconstruction.
- Identify the physical disk by capacity and layout, using Windows 磁碟管理 for orientation.
- Open the corresponding physical disk or image in WinHex using read-only/view mode.
- Inspect LBA 0 and record all four entries at
0x1BE,0x1CE,0x1DE, 以及0x1EE. - Decode starting LBAs and lengths, then inspect candidate NTFS sectors using the correct logical-sector size.
- Keep inspection separate from writing. Test any proposed reconstruction on a copy and perform the validation above.
For a new controlled deletion test, save LBA 0 before deletion, immediately afterward, and after reconstruction. Also preserve the relevant boot sectors and a file inventory with hashes. Those records establish which bytes changed and whether the recovered files match the originals.
常見問題
刪除分割區等同於清除 MBR 嗎？
55 AA 簽名存在。若將 LBA 0 中的所有內容清除，將會刪除額外的資訊，且這屬於另一種操作。.為什麼 WinHex 能偵測到 NTFS，而 Windows 卻顯示為「未分配」？
MBR 條目中是否存在 E: 這個磁碟機代號？
備份的 NTFS 啟動區能否還原整個 MBR？
這項實驗能否預測 SSD 的恢復結果？
「狀態為『正常』」是否代表所有檔案都完好無損？
