Fig. 1 HDD Quantum Fireball Plus KA 9.1GB
The first thing I had to do was to search the donor archive of such an ancient twin brother of this drive with a working controller board. When this quest was completed, it became possible to carry out detailed diagnostic measures. After checking the motor windings for a short circuit and making sure of its absence, we install the board from the drive - the donor to the drive - the patient. We energize and hear the normal sound of the shaft spinning, passing the calibration test with loading the firmware, and after a few seconds the drive registers through the registers about its readiness to respond to commands from the interface.
Fig. 2 DRD DSC indicators indicate readiness to accept commands.
We reserve all copies of the firmware modules. We check the integrity of the firmware modules. There are no problems with reading the modules, but analysis of the reports shows that there are some oddities.
Fig. 3. Zone table.
We pay attention to the zone distribution table, we notice that the number of cylinders is 13845.
Fig. 4 P-list (primary list - a list of defects introduced during the production cycle).
We draw attention to too few defects and their localization. We look at the factory defects concealment log module (60h) and find that it is empty and does not contain any entries. Based on this, we can assume that in some of the previous service centers, some manipulations with the drive’s service area may have been done, and someone else’s module was accidentally or intentionally recorded, or the list of defects in the original was cleared. To verify this assumption, we create a task in Data Extractor with the options “create sector-by-sector copy” and “create virtual translator” enabled.
Fig. 5 Task parameters.
After creating the task, we look at the entries in the partition table in the zero sector (LBA 0)
Fig. 6 Master boot record and partition table.
At offset 0x1BE, there is a single record (16 bytes). The type of file system on the partition is NTFS, the offset to the beginning of the 0x3F (63) sector, the size of the partition is 0x011309A3 (18,024,867) sectors.
In the sector editor, open LBA 63.
Fig. 7 NTFS boot sector
According to the information in the NTFS boot sector, the following can be said: the sector size adopted in the volume is 512 bytes (the word 0x0200 (512) is written at offset 0x0B), the number of sectors in the cluster is 8 (byte 0x08 is written at offset 0x0D), the cluster size is 512x8 = 4096 bytes, the first MFT record is located at an offset of 6,291,519 sectors from the beginning of the disk (at offset 0x30 the quadruple word 0x00 00 00 00 00 00C 00 00 (786 432) is the number of the first MFT cluster. The sector number is calculated by the formula: Cluster number * the number of sectors in the cluster + shift before the start of the partition 786 432 * 8 + 63 = 6,291,519).
We pass to the sector 6 291 519.
Fig. 8
But the data contained in this sector is completely different from the MFT record. Although this indicates a possible incorrect broadcast due to an incorrect defect list, it does not prove this fact. For further verification, we will read the disk in 10,000 sectors in both directions relative to 6,291,519 sectors. And then we will search for regular expressions in the read.
Fig. 9 First MFT Record
In sector 6,291,551, we find the first MFT record. Its position differs from the calculated one by 32 sectors, and then a group of 16 records (from 0 to 15) continuously follows. In the shift table, enter the position of the sector 6 291 519 to move forward by 32 sectors.
Fig. 10
The position of record No. 16 should be at an offset of 12 551 431, but we find zeros there, instead of recording MFT. We will carry out a similar search in the vicinity.
Fig. 11 MFT Record 0x00000011 (17)
A large MFT fragment is detected, starting with record number 17 with a length of 53,646 records) with a shift of 17 sectors. For position 12 155 431 we will put a shift of +17 sectors in the shift table.
Having determined the position of MFT fragments in space, we can conclude that this does not look like a random failure and recording of MFT fragments by incorrect offsets. A version with an incorrect translator can be considered confirmed.
For further localization of shear points, we set the maximum possible displacement. To do this, we determine how much the final NTFS partition marker is shifted (copy of the boot sector). In Figure 7, at offset 0x28, the fourth word is the partition size value of 0x00 00 00 00 00 01 13 09 A2 (18,024,866) sectors. Let’s add the offset of the partition itself from the beginning of the disk to its length, we will get the offset of the final NTFS marker 18 024 866 + 63 = 18 024 929. As expected, there was no needed copy of the boot sector. When searching in the vicinity, it was detected with an increasing shift of +12 sectors relative to the last fragment of the MFT.
Fig. 12 Copy NTFS boot sector
We ignore another copy of the boot sector at offset 18 041 006, since it is not related to our section. Based on previous events, it was established that within the section there are interspersed from 61 sectors that “popped up” in the broadcast, which split the data.
We perform a full drive reading, which results in 34 unread sectors. Unfortunately, it is impossible to reliably guarantee that all of them are defects removed from the P-list, but it is advisable to take their position into account in further analysis, since in some cases it will be possible to reliably determine the shift points accurate to the sector, and not to the file.
Fig. 13 Disk reading statistics.
Our next task will be to establish the approximate places of the shifts (accurate to the file in which they arose). To do this, we will scan all the MFT records and build the chain of file locations (file fragments).
Fig. 14 The chains of the location of files, or their fragments.
Further, moving from file to file, we are looking for at what point instead of the expected file header there will be other data, and the desired header will be detected with a certain positive shift. And as the shift points are refined, we fill out the table. The result of its filling will be over 99% of the files without damage.
Fig. 15 List of user files (consent received from client for publishing this screenshot)
To establish point shifts in individual files, you can carry out additional work and, if you know the file structure, find intersperses of data that are not related to it. But in this task it was not economically feasible.
PS I would also like to appeal to colleagues in whose hands this disk has been before. Please be careful when working with the device firmware and reserve service data before changing anything, and also do not allow the problem to be deliberately aggravated if you are unable to agree with the client on the performance of work.
Next post: Self-diagnosis of hard drives and data recovery
Previous post: Saving on matches or recovering data from Seagate ST3000NC002-1DY166 grating HDD