本篇文章翻自R-TT
http://www.r-tt.com/Articles/Finding...rs/index.shtml
譯者:OSSLab thx and aweij
Finding Master Boot Record
尋找 MBR 決定 RAID 偏移
1. 打開所有文件 進入 Text/hexadecimal edi
2. 不要打開寫入,預防寫入資料
3. Write down the Windows disk signature for each object to recognize later which Editor's window belongs to which object.
Template pane for Disk2 and Disk3
For our case, the sector preceding the partition is 16,065.
" 在這個例子裏面, Sectors preceding partition為 16,065 "
Jump to that sector in the Editor and then search for the NTFS boot sector pattern.
The Sectors search field in the Text/hexadecimal editor
On the Search dialog box, enter EB 52 90 4E 54 46 53 20 20 20 20 (the NTFS boot sector always starts from these bytes) into the HEX field, select From current position and enter 0 in Search at offset.
Data in Search dialog box to start search for NTFS boot sector
The Editor finds this pattern at sector 8064 on Disk2 and Disk3.
Now select the Boot sector NTFS pattern on the Template pane.
Click image to enlarge
Disk2.arc opened in the Text/hexadecimal editor. NTFS boot sector pattern found. The same pattern is found on Disk3.arc.
Previously found parameters:
RAID offset: 0
Next we need to find the MFT (master file table) on the disk:
" 接著需要在DISK上尋找MFT "
1. We will try to find an approximate MFT offset from the RAID start:
MFT offset from the partition start in sectors = Logical Cluster Number for the file $MFT * Sectors per cluster+RAID offset = 786,432*8+0 = 6,291,456 sector
Now we can create such a RAID in R-Studio:
Click image to enlarge
RAID 5 object created in R-Studio
R-Studio finds a valid file system on the RAID (Partition 1)
Double-click Partition 1 to enumerate its files:
Click image to enlarge
Folder/File structure found by R-Studio
R-Studio shows a valid folder/file structure, which is a good symptom. To finally verify that we created the RAID with the correct parameters, you can preview a file. A file for the preview should be larger than the block size * (Number of disks -1). 128KB for our case.
Preview of file Picture 236.jpg
The file is previewed successfully. We have created a RAID with correct parameters.
轉自 http://www.osslab.org.tw/Storage/Data_Recovery/Theory/Raid_Recovery/Example
http://www.r-tt.com/Articles/Finding...rs/index.shtml
譯者:OSSLab thx and aweij
1. 3 顆硬碟 不知順序
2. File System: NTFS (created by Windows XP/2003 跟 Master Boot Record (MBR start block)
3. Type: Basic volume
恢復 Raid 所需參數
1. 磁碟順序
2. 條帶(Strip size ) 大小
3. 條帶順序
4. 磁碟偏移(Offset)
以下是以R Studio 專用磁碟映像格式:
Disk1.arc
Disk2.arc
Disk3.arc
"請留意這邊程式中的表示方式,就算R-Studio在Disk2.arc中找到Disk1 object,那並不一定是在Raid中的第一顆磁碟"
2. File System: NTFS (created by Windows XP/2003 跟 Master Boot Record (MBR start block)
3. Type: Basic volume
恢復 Raid 所需參數
1. 磁碟順序
2. 條帶(Strip size ) 大小
3. 條帶順序
4. 磁碟偏移(Offset)
以下是以R Studio 專用磁碟映像格式:
Disk1.arc
Disk2.arc
Disk3.arc
"請留意這邊程式中的表示方式,就算R-Studio在Disk2.arc中找到Disk1 object,那並不一定是在Raid中的第一顆磁碟"
Finding Master Boot Record
尋找 MBR 決定 RAID 偏移
1. 打開所有文件 進入 Text/hexadecimal edi
2. 不要打開寫入,預防寫入資料
3. Write down the Windows disk signature for each object to recognize later which Editor's window belongs to which object.
"註記 磁碟簽名 disk signature 在每一個object中, 讓之後的編輯可以被辨識是在每一個object中"
4. 搜索mbr 33 C0 8E D0 BC (this is a standard MBR start block, but in some cases it may be different) into the HEX field; then select From start position and enter 0 in Search at offset.
" 利用搜尋HEX碼的功能去找出我們要的 mbr 33 C0 8E D0 BC (這串HEX碼就是MBR的起始BLOCK, 每個CASE中的CODE不一定相同) ; 記得在下面的搜尋條件中選取"From start position" 以及 填入"0" 在" Search at offset(hex) "
5. Click OK to start searching.
Data in Search dialog box to begin search for the Master Boot Record (MBR)
Search results:
完全沒找到
Disk1.arc opened in the Text/hexadecimal editor
Click image to enlarge
Disk2.arc opened in the Text/hexadecimal editor. MBR pattern found.
Click image to enlarge
Disk3.arc opened in the Text/hexadecimal editor. MBR pattern found.
The result is that the Text/hexadecimal editor finds this pattern at address 00 on Disk2.arc and Disk3.arc; Disk1.arc shows only zeros. That means that the offset is 0, and Disk1.arc cannot be the first disk in the RAID.
(這句我覺得有問題)
" 我們在Hexview 編輯器利用搜尋於Disk 2 以及Disk 3找到的MBR Patterns , 在Disk1的相同位置是顯示0 ,那應該是表示偏移量為 0 , 且Disk 1 可以做為 Raid 中的 第一顆磁碟 "
Data in Search dialog box to begin search for the Master Boot Record (MBR)
Search results:
完全沒找到
Disk1.arc opened in the Text/hexadecimal editor
Click image to enlarge
Disk2.arc opened in the Text/hexadecimal editor. MBR pattern found.
Click image to enlarge
Disk3.arc opened in the Text/hexadecimal editor. MBR pattern found.
The result is that the Text/hexadecimal editor finds this pattern at address 00 on Disk2.arc and Disk3.arc; Disk1.arc shows only zeros. That means that the offset is 0, and Disk1.arc cannot be the first disk in the RAID.
(這句我覺得有問題)
" 我們在Hexview 編輯器利用搜尋於Disk 2 以及Disk 3找到的MBR Patterns , 在Disk1的相同位置是顯示0 ,那應該是表示偏移量為 0 , 且Disk 1 可以做為 Raid 中的 第一顆磁碟 "
(我也覺得有問題 by Wei)
同各位置 Disk2 and Disk3 as master bootstrap loader code. In our case, two disks have the same MBR data on the same place.
"同各位置 Disk2 及 Disk3 有 master bootstrap loader code. 在這個例子裡 , 兩個DISK有相同的MBR data 在同一個地方 "
"同各位置 Disk2 及 Disk3 有 master bootstrap loader code. 在這個例子裡 , 兩個DISK有相同的MBR data 在同一個地方 "
Now, as a second step, we need to find the NTFS boot sector.
"第二步 , 我們需要找到NTFS boot sector "
Take a look on the Sectors preceding partition field on the Template pane
" 打開Template pane 找到Sectors preceding partition 以及 Windows disk signature "
Template pane for Disk2 and Disk3
For our case, the sector preceding the partition is 16,065.
" 在這個例子裏面, Sectors preceding partition為 16,065 "
If this value is larger than 63, we should divide it by N -1, where N is the number of disks (in our case, N = 3), which gives us 8,032. This is an approximate position to start searching for the NTFS boot sector. We will start the search from this position to avoid finding false NTFS boot sectors that may remain from previous NTFS partitions.
" 如果這個數值超過63 , 我們應該把它分割為 N - 1 , (N 就是此RAID 的 DISK數量 在這個CASE裡面是3個) , 為了避免找到之前NTFS partitions中錯誤的NTFS boot sectors,所以我們指定一個大概是在開始搜尋NTFS boot sector的位置,大概在 8,032 處. "
Jump to that sector in the Editor and then search for the NTFS boot sector pattern.
" 利用HexView 在NTFS boot sector pattern中移動位置到我們要的sector "
The Sectors search field in the Text/hexadecimal editor
On the Search dialog box, enter EB 52 90 4E 54 46 53 20 20 20 20 (the NTFS boot sector always starts from these bytes) into the HEX field, select From current position and enter 0 in Search at offset.
" 在搜尋的作業視窗中, 選項選擇 "From current position"以及在" Search at offset(hex)" 中填入 0 ,後 搜尋 EB 52 90 4E 54 46 53 20 20 20 20 (因為NTFS boot sector 都是這些bytes開始) "
Data in Search dialog box to start search for NTFS boot sector
The Editor finds this pattern at sector 8064 on Disk2 and Disk3.
" 用這個編輯器在DISK 2 跟DISK 3 中找sector 8064 "
Now select the Boot sector NTFS pattern on the Template pane.
Click image to enlarge
Disk2.arc opened in the Text/hexadecimal editor. NTFS boot sector pattern found. The same pattern is found on Disk3.arc.
" 在DISK 2 中找到跟Disk 3 相同的 NTFS boot sector pattern "
"參照找到NTFS boot sector pattern 時得到的Bios parameters Block資料我們找到我們需要的資訊"
Required parameters that we have found
Bytes per sector: 512
Sectors per cluster: 8
Logical Cluster Number for the file $MFT: 786432
Bytes per sector: 512
Sectors per cluster: 8
Logical Cluster Number for the file $MFT: 786432
Previously found parameters:
RAID offset: 0
Next we need to find the MFT (master file table) on the disk:
" 接著需要在DISK上尋找MFT "
1. We will try to find an approximate MFT offset from the RAID start:
" 1. 接著開始試著由RAID 開始處找尋 接近的MFT 偏移量"
MFT offset from the partition start in sectors = Logical Cluster Number for the file $MFT * Sectors per cluster+RAID offset = 786,432*8+0 = 6,291,456 sector
" 分割區由起始sectors開始計算的MFT 偏移量 = Logical Cluster Number for the file $MFT * 每個叢集扇區+RAID 偏移量=786,432*8+0 = 6,291,456 sector "
If the RAID offset is not 0, we need to add the offset to the result of the equation above.
MFT start on the first disk = MFT offset from the partition start in sectors/(N-1) = 6,291,456/2 = 3,145,728
2. We will begin to search for the exact MFT start at a position a couple thousand sectors less than this value. Say, sector 3,140,000.
On the Search dialog box, enter "FILE" into the ANSI field, then select From current position and enter 0 in Search at offset.
This pattern is found at sector 10,241,463 on Disk2 and at sector 3,153,792 on Disk3.
First file record sector in Disk3. Start of a data block.
What is important: The signature FILE ends with 0, which means that the file record number is not overwritten with a fixup. If it had ended with * (FILE*), we would not have been able to proceed further in our search and would have needed to use another technique.
The pattern $.M.F.T. (HEX 24 00 4D 00 46 00 54) shows that this is a correct MFT beginning.
Because sector 3,153,792 is closer to our expected value of sector 3,145,728 than to sector 10,241,463, we may assume that Disk3 is the first disk in the RAID.
To proceed further, we need to keep in mind that a file record in MFT occupies two sectors, and that data is written to a RAID 5 successively, one data block to one disk, then the next data block to the next disk, and a parity block to the third disk. We can represent an example of such a scheme in the following table ...
MFT start on the first disk = MFT offset from the partition start in sectors/(N-1) = 6,291,456/2 = 3,145,728
2. We will begin to search for the exact MFT start at a position a couple thousand sectors less than this value. Say, sector 3,140,000.
On the Search dialog box, enter "FILE" into the ANSI field, then select From current position and enter 0 in Search at offset.
This pattern is found at sector 10,241,463 on Disk2 and at sector 3,153,792 on Disk3.
First file record sector in Disk3. Start of a data block.
What is important: The signature FILE ends with 0, which means that the file record number is not overwritten with a fixup. If it had ended with * (FILE*), we would not have been able to proceed further in our search and would have needed to use another technique.
The pattern $.M.F.T. (HEX 24 00 4D 00 46 00 54) shows that this is a correct MFT beginning.
Because sector 3,153,792 is closer to our expected value of sector 3,145,728 than to sector 10,241,463, we may assume that Disk3 is the first disk in the RAID.
To proceed further, we need to keep in mind that a file record in MFT occupies two sectors, and that data is written to a RAID 5 successively, one data block to one disk, then the next data block to the next disk, and a parity block to the third disk. We can represent an example of such a scheme in the following table ...
| RAID DISK 1 | Second RAID disk | Third RAID disk |
| PD | 1 | 2 |
| 3 | PD | 4 |
| 5 | 6 | PD |
... where the numbers represent the order in which the data blocks are written to their respective disks, and PD stands for the "parity of data" block.
(This table represents only an example, and the block order may be arbitrary in a general case.)
Here that means that the file record numbers in MFT will increase by one within one data block. Then the MFT will continue on another disk, where file record numbers will increase by one within its respective data block, the third disk containing the parity block. And so on.
So, to find the block size, we will look at the file record numbers on this disk to discover the place where they no longer increase by one. This place would mean the end of that data block. Then we will look at other disks to find the disk and the place on it where file record numbers in the MFT resume increasing by one. Then we will look at another disk to find where the MFT continues, and so on.
Such a search can be done by scrolling down the text in the Editor by two sectors.
On Disk 3 the data block ends in sector 3,153,919 with file record number 3F 00.
Last file record in Disk3. End of a data block is on the next sector (3,153,919).
Looking at other disks, we find that this MFT continues on Disk 1 in sector 3,153,792 with file record number 40 00 and ends in Sec: 3,153,919 with file record number 7F 00. And so on.
File record continues in Disk1. Start of a data block.
Last file record in Disk1. End of the data block is on the next sector (3,153,919)
The final results are represented in the Table below:
(This table represents only an example, and the block order may be arbitrary in a general case.)
Here that means that the file record numbers in MFT will increase by one within one data block. Then the MFT will continue on another disk, where file record numbers will increase by one within its respective data block, the third disk containing the parity block. And so on.
So, to find the block size, we will look at the file record numbers on this disk to discover the place where they no longer increase by one. This place would mean the end of that data block. Then we will look at other disks to find the disk and the place on it where file record numbers in the MFT resume increasing by one. Then we will look at another disk to find where the MFT continues, and so on.
Such a search can be done by scrolling down the text in the Editor by two sectors.
On Disk 3 the data block ends in sector 3,153,919 with file record number 3F 00.
Last file record in Disk3. End of a data block is on the next sector (3,153,919).
Looking at other disks, we find that this MFT continues on Disk 1 in sector 3,153,792 with file record number 40 00 and ends in Sec: 3,153,919 with file record number 7F 00. And so on.
File record continues in Disk1. Start of a data block.
Last file record in Disk1. End of the data block is on the next sector (3,153,919)
The final results are represented in the Table below:
| Disk1 | Disk2 | Disk3 |
| Sec: 3,153,792 Rec: 40 00 Sec: 3,153,918 Rec: 7F 00 Sec: 3,153,919 End of stripe | Sec: 3,153,792 No records Sec: 3,153,918 No records Sec: 3,153,919: End of stripe | Sec: 3,153,792 Rec: 00 00 Sec: 3,153,918 Rec: 3F 00 Sec: 3,153,919 End of stripe |
| Sec: 3,153,920 Rec: No records Sec: 3,154,046 Rec: No records Sec: 3,154,047 End of stripe | Sec: 3,153,920 Rec: C0 00 Sec: Sec: 3,154,046 Rec: FF 00 Sec: 3,154,047 End of stripe | Sec: 3,153,920 Rec: 80 00 Sec: 3,154,046 Rec: BF 00 Sec: 3,154,047 End of stripe |
| Sec: 3,154,048 Rec: 00 01 Sec: 3,154,174 Rec: 3F 01 Sec: 3,154,175 End of stripe | Sec: 3,154,048 Rec: 40 01 Sec: Sec: 3,154,174 Rec: 7F 01 Sec: 3,154,175 End of stripe | Sec: 3,154,048 Rec: No records Sec: 3,154,174 Rec: No records Sec: 3,154,175 End of stripe |
No records mean this is a parity block.
Example of a parity sector
Looking at the table above, we can find the following parameters:
Disk order:
First RAID disk Disk3.arc
Second RAID disk Disk1.arc
Third RAID disk Disk2.arc
Offset: 0
Stripe size: 128 sectors, or 65,536KB (64KB)
Stripe order: (PD stands for Parity of Data)
Example of a parity sector
Looking at the table above, we can find the following parameters:
Disk order:
First RAID disk Disk3.arc
Second RAID disk Disk1.arc
Third RAID disk Disk2.arc
Offset: 0
Stripe size: 128 sectors, or 65,536KB (64KB)
Stripe order: (PD stands for Parity of Data)
| First RAID disk | Second RAID disk | Third RAID disk |
| 1 | 2 | PD |
| 3 | PD | 4 |
| PD | 5 | 6 |
Now we can create such a RAID in R-Studio:
Click image to enlarge
RAID 5 object created in R-Studio
R-Studio finds a valid file system on the RAID (Partition 1)
Double-click Partition 1 to enumerate its files:
Click image to enlarge
Folder/File structure found by R-Studio
R-Studio shows a valid folder/file structure, which is a good symptom. To finally verify that we created the RAID with the correct parameters, you can preview a file. A file for the preview should be larger than the block size * (Number of disks -1). 128KB for our case.
Preview of file Picture 236.jpg
The file is previewed successfully. We have created a RAID with correct parameters.
轉自 http://www.osslab.org.tw/Storage/Data_Recovery/Theory/Raid_Recovery/Example
發表文章
0 意見: