In this blog post we'll give you some tips for using "Read Ignoring ECC" commands. ECC refers to the Error Correction Code, found in every sector.
How does "Read Ignoring ECC" work?
To understand "Read Ignoring ECC," you should first understand how a hard drive processes standard read commands. When processing a standard read, a hard drive will:
- read the entire content of the sector
- load it into the cache
- calculate the checksum of the user data part of the sector
- compare that checksum to the one retrieved from the Error Correction Code.
If the checksums match, or if the corruption is light enough to be automatically repaired by the ECC, then fully integral user data from the sector will be passed through the bus as a response to our read command. If the checksums do not match and the corruption is beyond what the ECC within the sector can repair, the read procedure will be automatically retried. Using standard read commands to access data is preferable, but if the drive is not capable of processing them then we have to look for other alternatives.
"Read Ignoring ECC" will do just that: ignore the ECC part of the sector and simply retrieve only what the drive could read from the user data part of the sector on the first attempt. By definition, this appears to be an extremely useful data recovery operation, but it has several serious limitations that must be taken into account.
Read Ignoring ECC vs. Read Long
One well known type of "Read Ignoring ECC" command is called "Read Long," which was included in LBA28 specifications ATA-1 to ATA-5 between 1994 and 2003 (at which point, a newer LBA48 ATA-6 specification was released). This is important because the new LBA48 specification dropped support for the "Read Long" command. When a specification becomes obsolete, hard drive manufacturers are no longer required to support the commands within it. Starting from 2003, manufacturers began slowly dropping support for the "Read Long" command in their new drives. Because this command only existed in LBA28 specifications, it can be used to address only the first 2^28 sectors, or 128 GB of any drive.
There are also other less known methods available to "Read Ignoring ECC" that work in LBA48 mode, so they can be used to address any part of the drive. However, hard drive manufacturers don't necessarily have to support these either. This means that you could receive vastly different responses to "Read Ignoring ECC" commands depending on the design of the hard drive being accessed.
Using the DeepSpar Disk Imager with "Read Ignoring ECC"
The DeepSpar Disk Imager (DDI) will automatically select the right command to use depending on the situation. You must keep in mind that modern hard drives could respond to this command in five different ways, and only one of those responses is helpful for your recovery efforts.
Response #1: The intended operation of the "Read Ignoring ECC" command, meaning you actually retrieve some valid user data and bypass the need for error correction. In this case, multiple "Read Ignoring ECC" attempts on the same sector should show similar hex results with only minor variations from one result to the next.
These results should look like real data in hex, which will of course vary. But the general idea is that it should have some similarities with surrounding sectors that were read using standard read commands. Real data also sometimes has English words visible within hex results. Because the ECC was bypassed, this data will be partially corrupted, but it's still preferable to nothing in many cases. The level of corruption in the result will be affected by the number of Read Ignoring ECC retries we make on each sector due to the statistical analysis feature used by DDI.
DDI makes an educated guess about the most likely sector content by calculating the most common values for each bit within the sector out of every available result. As such, the more "Read Ignoring ECC" retries we make, the more accurate the result should be. In some cases, it's even possible to obtain a fully integral read on a bad sector in this manner.
Response #2: Completely random data that has nothing to do with valid user data. In other words, the drive passes on meaningless read/write channel noise through the bus as a response to "Read Ignoring ECC". The drive will give completely different hex results for every "Read Ignoring ECC" attempt on the same sector.
Response #3: The drive indicates an Abort error and completely refuses to process the command. This is easy to identify: red A's will appear in the sector map for every sector where you apply "Read Ignoring ECC."
Response #4: Many modern drives automatically use the ECC within every sector for encrypting and decrypting the user data during normal operation. In this case, using "Read Ignoring ECC" commands will bypass the decryption process, and the drive will return useless encrypted data as a response. The drive will return similar results when using "Read Ignoring ECC" multiple times on the same sector, but these results will look like encrypted data rather than valid user data. Encrypted data should not have any particular patterns or full words visible in hex. The encryption algorithm tends to be consistent for each individual sector, so using "Read Ignoring ECC" on two sectors with the same contents should give two identical encrypted results.
Response #5: The last possibility is the rarest one and it can be difficult to identify. It involves the drive returning an unrelated section of its internal buffer as a response to "Read Ignoring ECC." Unfortunately this can look very differently from one drive to another. It's difficult to spot at times because the read result might appear to have some clearly defined patterns within it that closely resemble real data. The best way to identify this is to look at sectors which were read with "Read Ignoring ECC" and compare their contents to the surrounding sectors which were read using standard read commands. For example, if all surrounding sectors are filled with zeroes, and sectors which were accessed with "Read Ignoring ECC" have some data within them, then there is a high chance that this is an invalid result.
"Read Ignoring ECC" should only be used with Response #1, when the drive returns valid user data. With the other four cases, it would waste time and potentially reduce the quality of the resulting image by adding invalid data to it. As of 2015, most modern drives do not process "Read Ignoring ECC" commands correctly, but it can still be useful in some cases, especially when working on older drives.
What kind of data works best with "Read Ignoring ECC"?
If you're working on a drive which processes "Read Ignoring ECC" commands correctly, the next step would be to choose what type of data to focus on.
Reading every bad sector is usually not viable due to constraints of time and drive longevity. The type of data you recover with "Read Ignoring ECC" should be resistant to the negative effects of corruption. Various file system structures, such as boot sectors, MFT records, and catalog records, that consist of a large number of small strings of raw data are perfect candidates for "Read Ignoring ECC." Recovering even a few bytes of valid data will still be useful when parsing the file system, effectively allowing you to identify more files, folders, or partitions.
The closer the data is to a raw format, the less will be lost due to corrupted bits. For example, if you're working with a text file, PST file, or BMP file, and lose 10% of the file to corruption, you'll still recover the other 90% of the file. Only the corresponding 10% of the file will be lost. If it's a text file, then some characters within it will be corrupted, but the file will still be accessible and useful as a whole. On these types of files it can make sense to use "Read Ignoring ECC" to fill in bad sectors.
At the other end of the spectrum are highly-packed or archived files, such as JPG, MP3, or executable files. These types of files will usually become unusable, even if only a small percentage is lost due to corruption. Packed files rely on the sound structure of the file, so that a relevant client application can unpack them. If a part of the structure is lost, then the rest of the file is likely going to be impossible to unpack, so instead of a partial recovery you will get nothing. Encrypted data will also be frequently sensitive to corruption since losing even a few bytes can make the decryption process fail for that sector, leaving it encrypted and unusable. As such, it makes much less sense to use "Read Ignoring ECC" on packed or encrypted files.