[Feature request] Detect intentional errors by hashing and comparing successive reads of sectors when errors occur #898

New Issue

claunia · 2026-01-29T15:32:20Z

claunia commented

2026-01-29 15:32:20 +00:00

Originally created by @ehw on GitHub (Aug 23, 2022).

Originally assigned to: @claunia on GitHub.

Type

New command...

Description

To detect various errors that are intrinsic to the media itself (intentional errors, copy protection, etc), when errors are detected that aren't immediately correctable, read the sector a few consecutive times and hash it until there are at least 3 or more matches. The 2352 or 2048 byte value that occurs at least 3 times consecutively is evidence of an intentional error and should be included in the final dump uncorrected.

Context

This was discussed on VGPC and was suggested that I make a feature request for this.

Sometimes media can contain 'intentional' errors, or errors that are part of the mastering of the disc and aren't evidence of media deterioration or hardware malfunction. Errors that are caused by media deterioration or hardware malfunction (drive, cable, connector, motherboard, power, etc) will most likely than not result in sporadic results every time. For instance, if a disc has a scratch, a drive will not return the same 2352/2048 byte value for that particular sector in the area around the scratch every time, especially consecutively (one read attempt after another). However, if the error is indeed supposed to be there (either intentionally or unintentionally), the value of the sector should be exactly the same bit-for-bit with multiple read attempts, even better if those attempts that matched were returned consecutively. In cases like this, the error should be present in the dump as is and shouldn't be corrected.

This will help in moments when errors occur due to DRM or because the disc was mastered incorrectly (like CD-Rs mastered with 3 bad sectors toward the end of the disc).

Documentation

No response

Originally created by @ehw on GitHub (Aug 23, 2022). Originally assigned to: @claunia on GitHub. ### Type New command... ### Description To detect various errors that are intrinsic to the media itself (intentional errors, copy protection, etc), when errors are detected that aren't immediately correctable, read the sector a few consecutive times and hash it until there are at least 3 or more matches. The 2352 or 2048 byte value that occurs at least 3 times consecutively is evidence of an intentional error and should be included in the final dump uncorrected. ### Context This was discussed on VGPC and was suggested that I make a feature request for this. Sometimes media can contain 'intentional' errors, or errors that are part of the mastering of the disc and aren't evidence of media deterioration or hardware malfunction. Errors that are caused by media deterioration or hardware malfunction (drive, cable, connector, motherboard, power, etc) will most likely than not result in sporadic results every time. For instance, if a disc has a scratch, a drive will not return the same 2352/2048 byte value for that particular sector in the area around the scratch every time, especially consecutively (one read attempt after another). However, if the error is indeed supposed to be there (either intentionally or unintentionally), the value of the sector should be exactly the same bit-for-bit with multiple read attempts, even better if those attempts that matched were returned consecutively. In cases like this, the error should be present in the dump as is and shouldn't be corrected. This will help in moments when errors occur due to DRM or because the disc was mastered incorrectly (like CD-Rs mastered with 3 bad sectors toward the end of the disc). ### Documentation _No response_

claunia added the feature request device wontfix labels 2026-01-29 15:32:20 +00:00

claunia closed this issue

2026-01-29 15:32:21 +00:00

claunia commented

2026-01-29 15:32:23 +00:00

@claunia commented on GitHub (Aug 25, 2022):

What you're asking is impossible to do, otherwise it would've already be done.

Let me explain.

When you request a sector (or several) to be read , and it does not pass the error detection and/or correction algorithms, the drive returns no data, just an error indicator.

In the case of the ATA/SATA protocols this error is very barebones, mostly, "something bad happened, sorry".

In the case of the SCSI protocol (the one used even by SATA DVD drives) the error can be very VERY verbose, from things like "ECC P failed, but Q is OK" to "laser focus problem". While this sound marvelous, this can give us enough information to detect copy protected sectors, in real life, no firmware gives so much information. Sometimes even they return an error code that makes no sense at all, or a "VENDOR ERROR CODE" that means, only people with access to that specific firmware source code knows what it means (literally).

So, if Aaru would check the contents of the data buffer the operating system returns to us in case of an error we will encounter one of two things: a bunch of 0s (meaning all retries will appear to be the same data), random data from RAM (meaning all retries will appear to be different data).

To add insult to injury, the SCSI protocol indicates a command to tell the drive to DO RETURN data in case of error. Most drives do not support this command, and of the ones that say they do, most of them do not really do. This is what the --persistent argument enables. In case of error it will send the drive this command, and if the drive says it is supported, it will store whatever data it is returned into the image, but still consider it a failure, because we cannot know if the data really comes from the disc, and not just some random garbage from the drive's RAM.

Now now, the read as audio mode of Plextor and Libredrive-compatible drives, allows us to bypass the ECC P, ECC Q and EDC errors. It is already used when errors are retried, and its usage is planned to be enhanced in 6.0 and future versions.

But, what you ask, is, unfortunately, impossible to do. I very much tried in the early versions of Aaru with many many many drives to no avail.

Therefore, I must close this request as won't fix, sorry.

@claunia commented on GitHub (Aug 25, 2022): What you're asking is impossible to do, otherwise it would've already be done. Let me explain. When you request a sector (or several) to be read , and it does not pass the error detection and/or correction algorithms, the drive returns no data, just an error indicator. In the case of the ATA/SATA protocols this error is very barebones, mostly, "something bad happened, sorry". In the case of the SCSI protocol (the one used even by SATA DVD drives) the error can be very VERY verbose, from things like "ECC P failed, but Q is OK" to "laser focus problem". While this sound marvelous, this can give us enough information to detect copy protected sectors, in real life, no firmware gives so much information. Sometimes even they return an error code that makes no sense at all, or a "VENDOR ERROR CODE" that means, only people with access to that specific firmware source code knows what it means (literally). So, if Aaru would check the contents of the data buffer the operating system returns to us in case of an error we will encounter one of two things: a bunch of 0s (meaning all retries will appear to be the same data), random data from RAM (meaning all retries will appear to be different data). To add insult to injury, the SCSI protocol indicates a command to tell the drive to DO RETURN data in case of error. Most drives do not support this command, and of the ones that say they do, most of them do not really do. This is what the `--persistent` argument enables. In case of error it will send the drive this command, and if the drive says it is supported, it will store whatever data it is returned into the image, but still consider it a failure, because we cannot know if the data really comes from the disc, and not just some random garbage from the drive's RAM. Now now, the `read as audio` mode of Plextor and Libredrive-compatible drives, allows us to bypass the ECC P, ECC Q and EDC errors. It is already used when errors are retried, and its usage is planned to be enhanced in 6.0 and future versions. But, what you ask, is, unfortunately, impossible to do. I very much tried in the early versions of Aaru with many many many drives to no avail. Therefore, I must close this request as `won't fix`, sorry.

claunia referenced this issue

2026-01-29 15:43:36 +00:00

[PR #898] [MERGED] Solve divide by zero error #1189

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: aaru-dps/Aaru-aaru-dps#898