Page 346 of 354
Re: DiscImageCreator
Posted: Mon Dec 11, 2023 10:10 pm
by 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.
sarami wrote: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...
sarami wrote: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.
Re: DiscImageCreator
Posted: Mon Dec 11, 2023 11:52 pm
by 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?
Re: DiscImageCreator
Posted: Tue Dec 12, 2023 1:15 am
by Nemok
Jackal suggested that 'twindump' might help. I'll look for that program.
Re: DiscImageCreator
Posted: Tue Dec 12, 2023 1:20 am
by Jackal
Nemok wrote: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.
Re: DiscImageCreator
Posted: Tue Dec 12, 2023 2:54 am
by 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.
Re: DiscImageCreator
Posted: Wed Dec 13, 2023 4:23 am
by Nemok
sarami wrote: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 ?
Re: DiscImageCreator
Posted: Wed Dec 13, 2023 11:32 am
by 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.
Nemok wrote: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.
Re: DiscImageCreator
Posted: Wed Dec 13, 2023 2:20 pm
by Nemok
Thanks for the interesting link. I'll try the specific tool as soon as possible.
sarami wrote: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 ?
Re: DiscImageCreator
Posted: Thu Dec 14, 2023 3:45 am
by 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
Re: DiscImageCreator
Posted: Fri Dec 15, 2023 11:32 am
by sarami
Nemok wrote:- 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.