Redump Forum

Posted: **Wed Jul 30, 2014 10:10 am**

sarami wrote:If so, I can code it but I can't test. Because I don't have already WinXP

Code it, I have damaged discs likely recoverable via many rereads and the SysInternals' Desktops (so processes which will take a lot of time won't mess my main desktop and distract me) to test the FUA function.

Posted: **Wed Jul 30, 2014 2:11 pm**

A bug was able to reappear when I uninstalled SPTD.(http://www.duplexsecure.com/en/downloads)

Code: Select all

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on H is  PLEXTOR  CD-R   PX-W5224A 1.04

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)

Code: Select all

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on M is  PLEXTOR  DVDR   PX-755A   1.08

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)

And I uploaded exe to test.
http://www.mediafire.com/download/dqzkl … stD8FUA.7z
To test, I changed below.
(SCSIOP_PLEX_READ_CD is 0xd8, CDB_FORCE_MEDIA_ACCESS is 0x08)

Code: Select all

BOOL ReadCDForFlushingDriveCache(
    PDEVICE pDevice,
    INT nLBA
    )
{
#if 0
    CDB::_READ12 cdb = { 0 };
    cdb.OperationCode = SCSIOP_READ12;
    cdb.ForceUnitAccess = CDB_FORCE_MEDIA_ACCESS;
    cdb.LogicalUnitNumber = pDevice->address.Lun;
    cdb.LogicalBlock[0] = HIBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlock[1] = LOBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlock[2] = HIBYTE(LOWORD(nLBA + 1));
    cdb.LogicalBlock[3] = LOBYTE(LOWORD(nLBA + 1));
#else
    CDB::_PLXTR_READ_CDDA cdb = { 0 };
    cdb.OperationCode = SCSIOP_PLEX_READ_CD;
    cdb.Reserved0 = CDB_FORCE_MEDIA_ACCESS;
    cdb.LogicalUnitNumber = pDevice->address.Lun;
    cdb.LogicalBlockByte0 = HIBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlockByte1 = LOBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlockByte2 = HIBYTE(LOWORD(nLBA + 1));
    cdb.LogicalBlockByte3 = LOBYTE(LOWORD(nLBA + 1));
    cdb.TransferBlockByte3 = 1;
#endif
    BYTE byScsiStatus = 0;
    if (!ScsiPassThroughDirect(pDevice, &cdb, CDB12GENERIC_LENGTH, NULL,
        0, &byScsiStatus, _T(__FUNCTION__), __LINE__)
        || byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
        return FALSE;
    }
    return TRUE;
}

Result:
I understood that I did not work as expected.

Code: Select all

ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    197/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    198/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    199/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    200/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    201/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8

If you think that FUA exists in 0xd8 command, please teach me it except for CacheExplorer.

Posted: **Wed Jul 30, 2014 3:02 pm**

Could you finally fix the rereading for C2 errors? It doesn't work in the Test (20140720) version, it doesn't work in the Release(20140621), only works in the old 2013 releases.

Change reading speed: 4x
Reread times 1, ErrSectorNum 48/ 48
Reread times 2, ErrSectorNum 48/ 48
C2 error was fixed at all

Change reading speed: 4x
Reread times 1, ErrSectorNum 51/ 51
Reread times 2, ErrSectorNum 51/ 51
Reread times 3, ErrSectorNum 2/ 2
Reread times 4, ErrSectorNum 2/ 2
C2 error was fixed at all

Change reading speed: 4x
Reread times 1, ErrSectorNum 51/ 51
Reread times 2, ErrSectorNum 51/ 51
Reread times 3, ErrSectorNum 2/ 2
Reread times 4, ErrSectorNum 1/ 1
Reread times 5, ErrSectorNum 1/ 1
C2 error was fixed at all

So it rereads 3-4 times and says all the errors are fixed, but nothing is fixed, it's a bug. Releases from 2013 reread properly.

Posted: **Wed Jul 30, 2014 3:10 pm**

EAC's developer should know something, because EAC has D8 support for these vintage SCSI CD-ROM readers, for C2 pointers and for FUA (-usefua parameter, and you have to configure drive as non-caching one).

And:

Code: Select all

SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    379/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    380/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    381/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    382/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    383/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    384/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    385/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    386/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    387/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    388/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    389/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    390/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    391/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    392/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8

So that only normal 0xA8 command is valid for FUA, and you cannot use this one for extracting data sectors in scrambled form.

Posted: **Wed Jul 30, 2014 7:06 pm**

Just program a new tool that can test if a drive supports 0xD8 FUA, if cachex is unreliable

Posted: **Thu Jul 31, 2014 7:45 pm**

sarami wrote:And I uploaded exe to test.
http://www.mediafire.com/download/dqzkl … stD8FUA.7z

Works here:

DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4
OS
Windows 7 Ultimate Service Pack 1 64bit
AppVersion
x86, AnsiBuild, Jul 31 2014 03:39:08
CurrentDir
D:\1
InputPath
path: dump
drive:
dir:
fname: dump
ext:
Start: 2014-08-01(Fri) 04:43:14
Checking reading lead-out
Creating bin from 4419 to 4421 (LBA) 4421
Reading lead-out: OK
Allocating memory for C2 error: 1024/1024
Operation Code: 0xd8, Sub Code: Raw
Creating img(LBA) 4420/ 4418
C2 error didn't exist
Copying .scm to .img
Descrambling data sector of img(LBA) 3250/ 3250
Checking ecc/edc LBA 4418/ 4418
User data vs. ecc/edc match all
Creating bin, cue, ccd(Track) 2/ 2
Free memory for C2 error: 1024/1024
Calculating hash: dump (Track 1).bin
Calculating hash: dump (Track 2).bin
Calculating hash: dump.img

End: 2014-08-01(Fri) 04:43:42

https://redump.info/disc/8037/ - this game.

But I've updated Daemon Tools yesterday, cachex shows now:

cachex.exe -i -p -c h:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on H is PLEXTOR DVDR PX-760A 1.07
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands:
[+] Plextor flush command: rejected
[+] Testing cache line size:

So maybe it works because of new DT with SPTD 1.86?

Posted: **Fri Aug 01, 2014 3:17 am**

F1ReB4LL wrote:Could you finally fix the rereading for C2 errors? It doesn't work in the Test (20140720) version, it doesn't work in the Release(20140621), only works in the old 2013 releases.

I'll check it.

F1ReB4LL wrote:DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4

If you use FUA, please use /f option.

Posted: **Fri Aug 01, 2014 4:19 am**

Is the offset correction applied for the C2 pointers as well? Perhaps this has something to do with the recent bug I discovered, C2 file was bigger than expected.

Posted: **Fri Aug 01, 2014 6:15 am**

sarami wrote:
F1ReB4LL wrote:DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4
If you use FUA, please use /f option.

Yes, with /f it fails

Code: Select all

...
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)     25/250866[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
...

Posted: **Fri Aug 01, 2014 6:34 pm**

Observe this carefully in the sample you have posted. If you compare R-W data extracted via these two modes, they look different.

====== Check SubP to W, OperationCode: 0xbe, Subcode: 1(=Raw) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 00
S 00 00 00 00 00 00 00 00 00 00 00 03
T 00 00 00 00 00 00 00 00 00 00 00 02
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 00
W 00 00 00 00 00 00 00 00 00 00 00 02

====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x08(=Raw) ======
Sub Channel LBA 0
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
P ff ff ff ff ff ff ff ff ff ff ff ff
Q 41 01 01 00 00 00 00 00 02 00 28 32
R 00 00 00 00 00 00 00 00 00 00 00 01
S 00 00 00 00 00 00 00 00 00 00 00 03
T 00 00 00 00 00 00 00 00 00 00 00 02
U 00 00 00 00 00 00 00 00 00 00 00 00
V 00 00 00 00 00 00 00 00 00 00 00 03
W 00 00 00 00 00 00 00 00 00 00 00 00

Two samples I have prepared for you:

http://www.mediafire.com/?lhad50oqouoznsv

C2 + Raw sub 96 extracted via certain method via D8 command, and the same thing via BE command, audio trap disc (so subcodes will be always properly aligned in the BE mode, especially true for certain buggy drives which lose the sync in the data-audio [or viceversa] transitions) method. Both look at first sight more or less identical. They contain lots of random errors, as expected for a subcode extracted without any class of rereadings/cleanings and whatnot, though.

I am wondering if this pattern could be predictable. And the reason of its existence: intentional, an accidental mastering artifact...?

Redump Forum

DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator