DiscImageCreator

[Jackal]

Here's a type of SecuROM that seems to be different from all previous types:

https://redump.info/disc/45559/

https://redump.info/disc/58232/

The things that are unclear to me:

- For Diablo II: Lord of Destruction, SecuROM sector 157 was not included in the SubIntention. What was causing this?

- Could the write offset of +576 be wrong? it's -12 plus 588 samples (1 sector). I've never seen this offset before.

- Can you plz double check if the SecuROM data is correct and if there are really 99 "modified" sectors for this SecuROM version?

Here are the log files for Diablo, and also an unmodified CloneCD.sub from another drive:
https://www50.zippyshare.com/v/jUraqxWb/file.html
https://www50.zippyshare.com/v/dVsXalzo/file.html

Thx for your help

[sarami]

Uploaded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file But I haven't tested yet because I don't have same type of SecuROM.

- Could the write offset of +576 be wrong? it's -12 plus 588 samples (1 sector). I've never seen this offset before.

Colin McRae Rally 2.0 https://redump.info/disc/31587/
This disc has also same issue.
1. OpCode[0xd8]: SubCode[0] shows -59.
2. OpCode[0xd8]: SubCode[2] shows -647.
3. OpCode[0xd8]: SubCode[8] shows -647.

I think -647 is correct.

[sarami]

Seems to be a bug with the Linux DIC. No dat is created.

Windows build uses xmllite, but this library doesn't support other OS, so linux build hasn't supported to output the xml doc yet, not bug.

20181229 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar
added: output dat (tinyxml2 is used.)

[Jackal]

Uploaded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file But I haven't tested yet because I don't have same type of SecuROM.

- Could the write offset of +576 be wrong? it's -12 plus 588 samples (1 sector). I've never seen this offset before.

Colin McRae Rally 2.0 https://redump.info/disc/31587/
This disc has also same issue.
1. OpCode[0xd8]: SubCode[0] shows -59.
2. OpCode[0xd8]: SubCode[2] shows -647.
3. OpCode[0xd8]: SubCode[8] shows -647.

I think -647 is correct.

So is it safe to assume that all discs in the database with -59 offset are actually -647, and +576 are actually -12?
Is it possible that other offsets are also affected?
And securom data remains the same? (the test version produces the same data)

And what about audio tracks that are dumped with -59 offset? (I'm not sure if there are any)

[sarami]

So is it safe to assume that all discs in the database with -59 offset are actually -647, and +576 are actually -12?
Is it possible that other offsets are also affected?

I'm not sure about it, but many sony dadc discs have -647. At least, I hope all 99 modified SecuROM discs are dumped again to get _disc.txt.

And securom data remains the same? (the test version produces the same data)

SubCode[0] dumps only main-channel. dic only uses this to output offsets in _disc.txt. No problem about sub-channel.
Or does this question mean that SecuROM sector 157 haven't fixed yet?

And what about audio tracks that are dumped with -59 offset? (I'm not sure if there are any)

Perhaps main-channel is shifted for 1 sector if discs are dumped by old method (isobuster+eac, perfectrip+eac)

[Jackal]

I'm not sure about it, but many sony dadc discs have -647. At least, I hope all 99 modified SecuROM discs are dumped again to get _disc.txt.

Does your Colin McRae Rally 2 disc also have -59 in one mode?
I guess we only need to check a couple discs and if they all have this problem, just fix all -59 discs to -647.
I dont know if this also affects discs with +588 offset which should be 0? Many discs have +588.

SubCode[0] dumps only main-channel. dic only uses this to output offsets in _disc.txt. No problem about sub-channel.
Or does this question mean that SecuROM sector 157 haven't fixed yet?

No, this was the only disc

[ajshell1]

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on https://redump.info/disc/38957/.

I'm going to test and see if the dump DIC produces matches the DB version.  I doubt it will.

Edit: Nope. No it doesn't.

Also, there's this forom the EdcEcc.txt log:

LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060081, 0x0eab1], MSF[13:23:06], mode 1


EDIT2:

I'm getting a similar issue with what appears to be https://redump.info/disc/40523/. The PVD and file size is the same.

LBA[059462, 0x0e846], MSF[13:14:62], mode 1
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059473, 0x0e851], MSF[13:14:73], mode 1

EDIT3:
What seems to be https://redump.info/disc/29992/ but doesn't match has SmartE detected.

LBA[000988, 0x003dc], MSF[00:15:13], mode 1
LBA[000989, 0x003dd], MSF[00:15:14], mode 1 User data vs. ecc/edc doesn't match
LBA[000990, 0x003de], MSF[00:15:15], mode 1 User data vs. ecc/edc doesn't match
LBA[000991, 0x003df], MSF[00:15:16], mode 1 User data vs. ecc/edc doesn't match
LBA[000992, 0x003e0], MSF[00:15:17], mode 1 User data vs. ecc/edc doesn't match
LBA[000993, 0x003e1], MSF[00:15:18], mode 1 User data vs. ecc/edc doesn't match
LBA[000994, 0x003e2], MSF[00:15:19], mode 1 User data vs. ecc/edc doesn't match
LBA[000995, 0x003e3], MSF[00:15:20], mode 1 User data vs. ecc/edc doesn't match
LBA[000996, 0x003e4], MSF[00:15:21], mode 1 User data vs. ecc/edc doesn't match
LBA[000997, 0x003e5], MSF[00:15:22], mode 1 User data vs. ecc/edc doesn't match
LBA[000998, 0x003e6], MSF[00:15:23], mode 1 User data vs. ecc/edc doesn't match
LBA[000999, 0x003e7], MSF[00:15:24], mode 1


EDIT4: More details here: /viewtopic.php?p=48494#p48494

[sarami]

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on https://redump.info/disc/38957/.

All logs of your smartE discs, please.

Does your Colin McRae Rally 2 disc also have -59 in one mode?

According to disc.txt, Colin McRae Rally 2.0 and Diablo II: Lord of Destruction have incorrect main-channel(all zero) on LBA 0 if OpCode[0xd8]: SubCode[0] is used.
SubCode[2] and SubCode[8] are no problem. I think this is a bug of plextor and perhaps this occurs on 99 modified SecuROM discs only.

Also I tried 'cdtoimg d8 hacked' for Colin McRae Rally 2.0. 2 files are uploaded. http://www.mediafire.com/file/763drz13a … mr.7z/file

Btw, old plextors have similar issue about drive offsets. These issues occur on all discs.

Code: Select all

  PLEXTOR PX-W820T  : +354(subch is 0x02), +355(subch is 0x00)
  PLEXTOR PX-W8220T : +354(subch is 0x02), +355(subch is 0x00)
  PLEXTOR PX-W124S  : +942(subch is 0x02), +943(subch is 0x00)
  PLEXTOR PX-W1210S : +686(subch is 0x08), +98(subch is 0x00)
  PLEXTOR PX-W1610TA: +686(subch is 0x02), +98(subch is 0x00)
  PLEXTOR PX-W2410TA: +686(subch is 0x02), +98(subch is 0x00)
  PLEXTOR PX-320A   : +686(subch is 0x02), +98(subch is 0x00)

I dont know if this also affects discs with +588 offset which should be 0? Many discs have +588.

Sega Saturn discs of +588 offset have a duplicated sector in lead-in. Due to this sector, the offset is shifted by 1 sector. If you worry about it, you can check the lead-in sectors.

[ajshell1]

Logs
https://cdn.discordapp.com/attachments/ … Disc_1.zip

https://cdn.discordapp.com/attachments/ … Disc_1.zip

https://cdn.discordapp.com/attachments/ … ia_USA.zip

[sarami]

Test version
20190103 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190103 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

fixed: detecting smartE