This specific version of this specific DRM seems to intentionally set the user data of sectors 299-1498 such that the scrambled data physically on the disc is all 0x00. During reading with a plextor, 16 sectors in that range give C2 errors, and additional non-C2 sectors in that range provide inconsistent data (non-reproducible hashes). The ASUS dumps also return those 16 C2 errors, as well as an additional 16 C2 errors (covering the locations of inconsistent sectors for the plextor).
[TECHNICAL DETAILS]
In the absence of better dumping hardware (EFM dumps, etc), I can only speculate as to the cause. My best guess is that the DRM is designed to make creating CD-Rs difficult, or make CD-Rs unplayable due to how burners at the time would have dealt with this intentional mastering 'error'. From the reading perspective, the drives may be getting invalid Digital Sum Values from all the 0x00 (similar to safedisc weak sectors), or something like that, resulting in C2 errors and inconsistencies.
[/TECHNICAL DETAILS]
I suggest for this protection scheme that the sectors in the 299-1198 range should be manually fixed to have valid sync headers, linearly incrementing MSF and scrambled 0x00 user data (Mode 2 Form 2), with 0x00 EDC, as it seems that is what is actually on the disc (but our drives are unable to read it). Based on prior inspection there are likely 20 or so sectors that need fixing, around LBA 300-370 (location differs for each dump on Plextors), or in the case of the ASUS dumps, the 32ish C2 errors need fixing in the way I described.
This can all be accomplished automatically by dumping with an ASUS drive and modified redumper that fills in C2 errors with fixed MSF and scrambled 0x00, rather than the default 0x55
