DiscImageCreator

[Nemok]

I'm a bit confused. I thought that :

- reading forwards was keeping twin #1 and ignoring twin #2 of each duplicated sector since disc drives were considering any repeated sector as erroneous, and so backwards was keeping twin #2 and ignoring twin #1 since twin #2 was read first this way.
- twin sectors were called twins for their identical headers while possibly containing totally different data thus making it possible to hide data in every twin #2.

If so, comparing forwards and backwards images can not reveal twins that happen to contain strictly identical data, if such cases exist. But I don't know that.

But Jackal says "Disc has 260 twin sectors in range 329687-329947".

About the principle of that range being larger than the range of sectors with differences you found, I guess it's still possible. But there's a mistake anyway since range 329687-329947 has 261 sectors, not 260...

Twin sectors of the Tages are always 260 sectors? If yes, where is the evidence to show that it is correct?

"That is the question." Personally for now, I'm just curious about comparisons between forwards and backwards images for other Tages protected discs.

[sarami]

I tried to dump at several time from 329687-329947 using /r
1. CRC32: 26F4EEC3 (ASUS)
2. CRC32: 200728C2 (ASUS)
3. CRC32: 0F5D94C2 (ASUS)
4. CRC32: 5DFECCCA (PLEXTOR)
5. CRC32: 3779DF3B (PLEXTOR)

These are always different hashes. Did Jackal really obtain identical hashes?

[Nemok]

Jackal suggested that 'twindump' might help. I'll look for that program.

[Jackal]

But there's a mistake anyway since range 329687-329947 has 261 sectors, not 260...

Hi, I'm not sure what was the case here, but yeah mentioned range is 261.

How I remember it is that you need to end up with an x amount of sequential sectors that differ from the normal read sectors and they are correct with matching ECC/EDC.

If you are getting different results each time, then each of those ranges is either a mixture of normal + twin sectors or there may be corrupted/scrambled sectors. Guess you need to do this manually or make some automated tool that rereads each sector until the twin sector is obtained.

[sarami]

PLEXTOR can get the identical hash when uses /f (cache delete), but sometimes returns non-identical hash.
ASUS can't get the identical hash even if uses /f.

[Nemok]

PLEXTOR can get the identical hash when uses /f (cache delete), but sometimes returns non-identical hash.
ASUS can't get the identical hash even if uses /f.

Same thing with this disc: https://redump.info/disc/36124/ using this command: "data d: dump.bin 8 0 293587 /be raw /f /r".
A first error happened near the end of the disc where twin sectors are expected :

Code: Select all

LBA[288180, 0x465b4]: [F:ProcessReadCD][L:282]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
LBA[288180, 0x465b4]: Read error. padding [2352 bytes]
========== LBA[288180, 0x465b4]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 63 48 50 00   ............cHP.
LBA[288180, 0x465b4] Reread NG

So I started focusing on 287000-289000:
- attempt #1: EC8893EC
- attempt #2: E43FF68D
- attempt #3: 6D3297FE

Then narrowing the suspected range to 287500-288500 since:
- 287000-287500 always gives D7F637B0
- 288500-289000 always gives BB08138A

What do you think of using hashes inconsistency to help detect the range of twin sectors by narrowing the suspected range further ?

[sarami]

I found the explanation at CDFreaks. https://web.archive.org/web/20070615215 … es-blunder

And Jackass writes the memo in the uploaded file.

Notes:
------

I have successfully used this utility to backup XIII CD's 2, 3, and 4
Please see my other program BGEScan if you wish to backup Beyond Good and Evil CD3

You might like to try the following data

Title        Sector Start    Sector End
------------------------------------------
XIII CD2    281170        281424
XIII CD3    274371        274625
XIII CD4    287915        288169

I'm not sure these ranges are correct.

Then narrowing the suspected range to 287500-288500 since:
- 287000-287500 always gives D7F637B0
- 288500-289000 always gives BB08138A

If these sectors matches the forward-sectors, it's not tages sectors.

[Nemok]

Thanks for the interesting link. I'll try the specific tool as soon as possible.

I'm not sure these ranges are correct.

With successive manual retries, I finally found 287920-288165 to be exact, not 287915-288169.

About DIC, one thing I noticed on a non protected area: output without /r for LBA 1000 to 2000 = output with /r for LBA 1000 to 1999 (and not 1000 to 2000, otherwise output has 1 additional sector). Is it normal ?

[Nemok]

Getting to the point for https://redump.info/disc/36124/

Testing range 287900-288200 with twindump
- 251 twin sectors in 287922-288172
Backwards reading hashing for range B sectors
- identical CRC-32 found : 57A7CE8A

Testing range 287900-288200 with DIC
Forwards and backwards reading comparison
- 251 twin sectors in 287922-288174 with the 2 last sectors all 0x55
- 251 twin sectors in 287922-288180 with the 8 last sectors all 0x55 or invalid mode
Backwards reading hashing for range B sectors
- no identical CRC-32 found
- hashes inconsistency is not reliable enough to help detect the range of twin sectors

[sarami]

- 251 twin sectors in 287922-288174 with the 2 last sectors all 0x55
- 251 twin sectors in 287922-288180 with the 8 last sectors all 0x55 or invalid mode
Backwards reading hashing for range B sectors
- no identical CRC-32 found
- hashes inconsistency is not reliable enough to help detect the range of twin sectors

Thanks test. As Jackal says, it needs to reread each sector until the twin sector is obtained.