1 Topic by scsi_wuzzy (edited by scsi_wuzzy 2018-08-30 19:58:46)

  • Registered: 2015-02-24
  • Posts: 101

I've been going through and dumping all my PC games, and I've noticed that a number of SecuROM protected discs don't end up with hashes matching the ones in the database. For multi-disc games, this often only happens for the SecuROM protected discs. For example, I just dumped Aliens Versus Predator 2, and my Disc 1 (which has SecuROM) has a matching size but not a matching hash when compared with http://redump.org/disc/12832/. Disc 2 (which doesn't have SecuROM) has a matching size and hash. While it's certainly possible it's just a pressing difference (my Disc 1 is manufactured by TECHNICOLOR just like the one in the database, and has the same IFPI number, but some parts of the mastering ring differ), I've seen this with several discs so I wanted to inquire. I know that the current DICUI releases run the ECC checker and it replaces the bad sectors (SecuROM sectors) with dummy data. Is it possible that some entries predate this dummy data replacement, or that maybe some other dummy data was used? Or is this definitely a pressing difference?

My setup: Dumping with DICUI and a Plextor PX-760A. I've tried redumping discs that don't match, and I've always gotten identical hashes between the two dumps. No unintentional C2 errors reported by the drive. When checking hashes, I'm using the "!submissioninfo" file generated by DICUI. I've also hashed with 7-ZIP and got the same thing.


Edit: I think this was a bug with DIC. I updated to the newest release and got a matching hash.

  • user7
  • Moderator
  • Offline
  • Registered: 2009-03-14
  • Posts: 2,621

Can you post your logs for the example you referred to: http://redump.org/disc/12832/

smile

All my posts and submission data are released into Public Domain / CC0.

3 Reply by reentrant (edited by reentrant 2018-08-30 18:22:49)

  • Registered: 2014-10-06
  • Posts: 704

ECC checker should not replace sectors for such discs with 0x55. For most cases it's just different mode sector perfectly readable by optical drive. Are you sure the differences stem from that single sector near the end of the disc?

EDIT: I have my custom tool for checking sectors for errors & custom fixer... I think it's time to release it...

4 Reply by Landcross (edited by Landcross 2018-08-30 18:50:06)

  • Registered: 2018-04-20
  • Posts: 177

A few days ago I had some problems with SecuROM and my Plextor 760A. Jackal posted about it here: http://forum.redump.org/post/62811/#p62811

I don't know very much about this stuff, but maybe it was the same problem as you have. The issue has been fixed (at least in my case) in the newest DIC. Try updating DIC to the newest version and see if that fixes the issue. The newest version can be downloaded here: https://github.com/saramibreak/DiscImag … g/20180828

If you're already on that version, than you need someone with actual knowledge about this stuff, not me wink

  • Registered: 2015-02-24
  • Posts: 101

user7 wrote:

Can you post your logs for the example you referred to: http://redump.org/disc/12832/

I've compressed everything from the dump except the actual data. I was just going to post on Pastebin or similar, but some logs (like the EdcEcc output) are huge. https://www.dropbox.com/s/578x418z8712h … _1.7z?dl=0

reentrant wrote:

ECC checker should not replace sectors for such discs with 0x55. For most cases it's just different mode sector perfectly readable by optical drive. Are you sure the differences stem from that single sector near the end of the disc?

It's possible I was getting some parts of SafeDisc and SecuROM confused in my discussion. However, there are in fact sectors getting replaced with 0x55 in this dump. I dumped it again, and the hashes for both the raw scrambled data and descrambled data matched. Initially I thought maybe that, if there are read errors (though I would expect C2 errors if that was the case, and there aren't any), maybe the hashes were just matching because the error sectors were being replaced with identical data between reads. However, since the raw scrambled data matches, I believe this means that the reads are consistent.

The disc looks good, in terms of condition. I'm wondering if there are some weird mastering/manufacturing errors, perhaps.

6 Reply by scsi_wuzzy (edited by scsi_wuzzy 2018-08-30 20:03:09)

  • Registered: 2015-02-24
  • Posts: 101

Landcross wrote:

A few days ago I had some problems with SecuROM and my Plextor 760A. Jackal posted about it here: http://forum.redump.org/post/62811/#p62811

I don't know very much about this stuff, but maybe it was the same problem as you have. The issue has been fixed (at least in my case) in the newest DIC. Try updating DIC to the newest version and see if that fixes the issue. The newest version can be downloaded here: https://github.com/saramibreak/DiscImag … g/20180828

If you're already on that version, than you need someone with actual knowledge about this stuff, not me wink

Thanks for the heads up. I'll drop in the new DIC into the DICIUI folder. Hopefully I don't have to go back and redump a bunch of stuff.

Edit: Apparently dropping in the newest CSS / DiscImageCreator / EDCECC causes DICUI to now crash after the dump, when it's collecting data for the submissioninfo file. Interesting.

Edit2: Looks like the crash is probably unrelated to the change in DIC. I think DICUI just crashes with that disc. Just installed VS Community to troubleshoot.

7 Reply by scsi_wuzzy (edited by scsi_wuzzy 2018-08-30 19:54:33)

  • Registered: 2015-02-24
  • Posts: 101

Sorry for the triple post, but it appears to have been a bug with DIC. I copied the new DIC executable over top of the version included in DICUI, and the hash for disc 1 now matches what's in the DB.

Now I gotta go see what else I need to redump.


Edit: If anyone wants to see the logs for the new dumps and compare with the old, let me know. I can upload them.