Redump Forum

Posted: **Mon Dec 24, 2018 4:02 pm**

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

Posted: **Tue Dec 25, 2018 9:07 am**

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.

Jackal wrote:- 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.

Posted: **Sat Dec 29, 2018 9:33 am**

sarami wrote:
FatArnold wrote: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.)

Posted: **Mon Dec 31, 2018 10:40 am**

sarami wrote: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.

Jackal wrote:- 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)

Posted: **Tue Jan 01, 2019 9:09 pm**

Jackal wrote: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.

Jackal wrote: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?

Jackal wrote: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)

Posted: **Wed Jan 02, 2019 1:50 am**

sarami wrote: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.

Jackal wrote: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

Posted: **Wed Jan 02, 2019 5:16 pm**

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

Posted: **Wed Jan 02, 2019 8:24 pm**

ajshell1 wrote: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.

Jackal wrote: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)

Jackal wrote: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.

Posted: **Wed Jan 02, 2019 9:24 pm**

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

Posted: **Wed Jan 02, 2019 10:06 pm**

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

Redump Forum

DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator