26

(3,493 replies, posted in General discussion)

Nemok wrote:

The program gets further but fails at checking subQ address for each track :

Uploaded.
https://github.com/saramibreak/DiscImag … 1844517155

27

(3,493 replies, posted in General discussion)

Nemok wrote:

Also discovered today :

Uploaded.
https://github.com/saramibreak/DiscImag … 1842949631

28

(3,493 replies, posted in General discussion)

Nemok wrote:

How to explain this ? Were previous DIC releases wrong about it ?

See subError.txt. Subchannel are all zero bytes.

LBA[000000, 0000000]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000000, 0000000]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 00 00 00 00 00 00 00 00 00 00 00 00
    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 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    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 00
LBA[000000, 0000000]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000000, 0000000]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000000, 0000000]: Track[01]: SubQ[13]:PrevTrackNum[01] -> [00]
LBA[000000, 0000000]: Track[01]: SubQ[19-21]:PrevAbs[149, 00:01:74], Abs[0, 00:00:00] -> [150, 00:02:00]
LBA[000000, 0000000]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0xf6]
LBA[000000, 0000000]: Track[01]: SubQ[23]:CrcLow[0000] -> [0xd8]
LBA[000001, 0x00001]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000001, 0x00001]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 00 00 00 00 00 00 00 00 00 00 00 00
    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 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    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 00
LBA[000001, 0x00001]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000001, 0x00001]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000001, 0x00001]: Track[01]: SubQ[15-17]:PrevRel[0, 00:00:00], Rel[0, 00:00:00] -> [-1, 00:00:255], [L:1421]
LBA[000001, 0x00001]: Track[01]: SubQ[19-21]:PrevAbs[150, 00:02:00], Abs[0, 00:00:00] -> [151, 00:02:01]
LBA[000001, 0x00001]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0xe3]
LBA[000001, 0x00001]: Track[01]: SubQ[23]:CrcLow[0000] -> [0x24]
LBA[000002, 0x00002]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[000002, 0x00002]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 00 00 00 00 00 00 00 00 00 00 00 00
    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 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    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 00
LBA[000002, 0x00002]: Track[01]: SubQ crc16 is 0. Main-channel may be corrupt
LBA[000002, 0x00002]: Track[01]: SubQ[12]:Adr[0] -> [0x01]
LBA[000002, 0x00002]: Track[01]: SubQ[15-17]:PrevRel[-1, 00:00:255], Rel[0, 00:00:00] -> [-2, 00:00:254], [L:1421]
LBA[000002, 0x00002]: Track[01]: SubQ[19-21]:PrevAbs[151, 00:02:01], Abs[0, 00:00:00] -> [152, 00:02:02]
LBA[000002, 0x00002]: Track[01]: SubQ[22]:CrcHigh[0000] -> [0x79]
LBA[000002, 0x00002]: Track[01]: SubQ[23]:CrcLow[0000] -> [0x16]
LBA[000003, 0x00003]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually

29

(3,493 replies, posted in General discussion)

Nemok wrote:

Pack mode without /c2 is still broken.

It's not broken. LG/ASUS does not support the pack mode.

30

(3,493 replies, posted in General discussion)

@Nemok, Lugamo
Thanks. I fixed it. https://github.com/saramibreak/DiscImag … issues/254

31

(3,493 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20231201
*2023-12-01
- added support non-plextor and non-lg/asus drive when data/audio command is used (but some drive failed to dump. e.g. SH-216BB)
- added again -D option in install command of makefile for linux
- added parsing PS3_DISC.SFB and PS3UPDAT.PUP
- added detecting protection (DUMMY.ZIP)
- added a flag indicating readable the lead-out sector (Using ASMedia SATA controller and linux, 0xF1 drive can read the lead-out sector using 0xbe)
- added checking if export, import, resource size are correct
- changed if sync or msf or mode is invalid, it skips descrambling
- changed EXELBA_STORE_SIZE
- fixed /be option
- fixed error sector reading
- fixed reading the multiple PARAM.SFO
- fixed reading PARAM.SFO
- fixed the crash when cab file was extracted
- fixed division by zero
- fixed DEBUG build error
- Updated driveOffset.txt

32

(52 replies, posted in General discussion)

https://github.com/saramibreak/UmdImage … s/tag/v1.6
## v1.6 (2023-12-01)
- added: support to dump PFI.bin

33

(52 replies, posted in General discussion)

https://www.mediafire.com/file/905y99zq … st.7z/file
Added: support to dump PFI.bin

34

(52 replies, posted in General discussion)

Edness wrote:

On PS2 the (DNAS) Disc ID is also 5 bytes long. 

Edness wrote:

PS3's Disc ID being 16 bytes long

How do we get it?

35

(52 replies, posted in General discussion)

unsigned char bufSPK[0x4000] = {};
void* p1 = _sceUmdManSPKGetMKI();
memcpy(bufSPK, p1, 0x4000);

It crashed by memcpy.

Edness wrote:

Normally it's supposed to just be a separate 5 byte buffer that's passed to the ReadMKI function anyway, so I'm not expecting much to be written there.

5 bytes = 40 bits. DVD has 40 bits key of CSS, so I've expected that UMD also has some kind of 40 bits key (media key?).

SPK is SPecial Key? SPecific Key?

36

(52 replies, posted in General discussion)

Edness wrote:

I am probably overthinking it, but do try the ReadMKI function with the SPKGetMKI address (if it allows you to write to kernel memory like that).  At worst it'll just blank out assembly instructions of the module and crash

The result is no error and no crash but buffer is all zero bytes except buffer[2].

37

(52 replies, posted in General discussion)

Edness wrote:

could you try calling sceUmdManSPKGetMKI() on its own and print out what address it returns?

    void* p = _sceUmdManSPKGetMKI();

p is 0x880f1240

Edness wrote:

sceUmdExecReadCapacityCmd() seems to be the only function that allows putting your own command as arg0, followed by the UMD drive as arg1 of course.

Yes. I've already comfirmed that this func can be called and succeeded.

    unsigned char bufCapa[8] = {};
    res = _sceUmdExecReadCapacityCmd(0x25, pUmdDrive, 8, bufCapa);

The result is here. (Dissidia 012: Duodecim Final Fantasy)

 00 0D 2C B0 00 00 08 00

1st 4 bytes show total sectors. It matches redump db. 2nd 4 bytes show the block size in bytes. It's always 0x800.

38

(52 replies, posted in General discussion)

I tried it. _sceUmdExecReadMKICmd() succeeded but bufMKI is all zero bytes except bufMKI[2].

    unsigned char bufMKI[448] = {};
    bufMKI[2] = 8;
    
    char* p = (char*)(0x08800000);
    memset(p, 0x00, 0x8000);
    sceKernelDcacheInvalidateRange(p, 0x4000);
    
    res = _sceUmdExecReadMKICmd(pUmdDrive, bufMKI, 8, p);

39

(52 replies, posted in General discussion)

Edness wrote:

but in theory if just the NIDs were known across the 3.70+ FWs, would that also work for UmdImageCreator to dump the PFI?  Or do you specifically need the full name too?

I assumed I needed a real function name, but it turned out that's not true. I confirmed that PFI can be dumped by 0x406E8F99.
Other functions have also already been analized by comparing the asm of 3.52 (Only 6.61).
https://github.com/saramibreak/UmdImage … alysis.txt

Edness wrote:

Edit 2

Thanks. Mostly as expected in relation to the opcode. I'm especially interested in sceUmdExecReadMKICmd. What is MKI? It's Media Key Identifier? Media Key Info???

40

(52 replies, posted in General discussion)

Edness wrote:

is the PFI data dumping currently only limited to FW 3.52 (or rather any FW below 3.70 where NIDs weren't randomized?)

Unfortunately yes.

Edness wrote:

in FW 6.60 and 6.61, sceUmdExecReadUMDStructureCmd() should use the NID 0x406E8F99 if my understanding is correct.

NID is correct but the correct function name is sceUmdExecReadUMDStructureCmd + 128 bits string.
https://uofw.github.io/upspd/docs/Silve … index.html

These new nids are not actually “random” but instead, they now append a new 128bit “randomising key” to the end of each string before the SHA1 hash is calculated. A 128bit value is almost impossible to bruteforce practically so these new nids cannot be cracked anymore.

For this reason, we cannot know the real function name. If quantum computers reach a practical level, they may solve the problem.

41

(52 replies, posted in General discussion)

Edness wrote:

It sends the command 0xBD, so your 2nd assumption is correct.  umd9660.prx seems to set the 2nd argument to 16, but I agree with the visible padding data that it's likely meant to be 14.  They probably just set it bigger just to be safe from accidentally truncating data.

Thank you.

Edness wrote:

I noticed there's sceUmdExecReadUMDStructureCmd() here too.

I changed the code and confirmed not to crash.

    unsigned char bufStruct[2064] = {};
    bufStruct[9] = 8;
    res = _sceUmdExecReadUMDStructureCmd(pUmdDrive, bufStruct, &bufStruct[16]);
    if (res < 0) {
        OutputPspError("_sceUmdExecReadUMDStructureCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecReadUMDStructureCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufStruct, sizeof(bufStruct));
        sceIoClose(uid);
        pspPrintf("_sceUmdExecReadUMDStructureCmd.bin is generated\n");
    }

Dissidia 012: Duodecim Final Fantasy

 00 00 00 00 00 00 00 00 FC 07 00 00 00 00 00 00
 08 00 00 00 80 00 31 E0 00 03 00 00 00 FC AB 2F
 00 09 C0 BF 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 :
 :
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

42

(52 replies, posted in General discussion)

@Edness
Do you know what data is outputted by sceUmdExecMechaStatCmd? This func is called by umd9660.prx. https://github.com/saramibreak/UmdImage … asm352.txt

I think it's Mechanical Status of Mode Sense (5Ah) or Mechanism Status (BDh).

    unsigned char bufMecha[16] = {};

    res = _sceUmdExecMechaStatCmd(pUmdDrive, 16, bufMecha);
    if (res < 0) {
        OutputPspError("_sceUmdExecMechaStatCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecMechaStatCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufMecha, sizeof(bufMecha));
        sceIoClose(uid);
        pspPrintf("_sceUmdExecMechaStatCmd.bin is generated\n");
    }

LocoRoco http://redump.org/disc/33078/

 00 00 00 00 00 01 00 04 80 00 00 00 27 09 27 09

Jigen Kairou http://redump.org/disc/54489/
Changed the buf size to 30.

 00 00 00 00 00 01 00 04 80 00 00 00 37 02 37 02
 37 02 37 02 37 02 37 02 37 02 37 02 37 02

Dissidia 012: Duodecim Final Fantasy http://redump.org/disc/25036/
Changed the buf size to 106.

 00 00 0D 2C AF 01 00 04 80 00 00 00 22 D9 22 D9
 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9
 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9
 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9
 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9
 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9 22 D9
 22 D9 22 D9 22 D9 22 D9 22 D9

It seems the correct buf size is 14.

43

(52 replies, posted in General discussion)

Edness wrote:

Looks like those functions might be meant for the DVD drive present on devkits? ... IsUmdDrive returns 0 or 1 if the (unsigned) value there is less than 1 (in other words a bool on whether the value is 0 or not.)  And both functions that later call sceUmdExecGetConfigurationCmd() and  sceUmdExecReadDiscInfoCmd(), first also call sceAtaIsUmdDrive() and exit out of it, if it doesn't return 0.

As you say, if sceAtaIsUmdDrive returns 0, that is NOT UMD DRIVE, sceUmdExecReadDiscInfoCmd is called.

    0x0000C794: 0x0C003FA5 '.?..' - call func sceAtaIsUmdDrive(delay)
    0x0000C798: 0x00000000 '....' - nop        
    0x0000C79C: 0x1040000E '..@.' - if($v0 == 0) goto loc_0000C7D8 (delay)

loc_0000C7D8:        ; Refs: 0x0000C79C 
    0x0000C7D8: 0x3C060393 '...<' - $a2 = 0x393 << 16
    0x0000C7DC: 0x0C0029D6 '.)..' - call func sceUmdManSetAlarm(delay)
    0x0000C7E0: 0x34C48700 '...4' - $a0 = $a2 | 0x8700
 :
 :
    0x0000C824: 0x2405000C '...$' - $a1 = 12
    0x0000C828: 0x0C001368 'h...' - call func sceUmdExecReadDiscInfoCmd(delay)

44

(3,493 replies, posted in General discussion)

user7 wrote:

DIC is treating intentional C2 errors (unlicensed) with /sf like regular C2 errors. keeps trying to re-read.

Looks like DUMMY.ZIP is triggering the issue (it's usually BIG.DAT).

Ok, I'll add it.

45

(52 replies, posted in General discussion)

Edness wrote:

Random side note: The C library functions (at least the two that I've encountered - strncmp(), and memset()) seem to be unnamed in your asm dump.  Instead they're generic SysclibForKernel_NID() names, but luckily JPCSP has a more complete list of resolved NID hashes which was useful in cases like these.

Added the fuction name in documents.
https://github.com/saramibreak/UmdImage … asm352.txt
https://github.com/saramibreak/UmdImage … m352_c.txt

46

(52 replies, posted in General discussion)

sceUmdExecGetConfigurationCmd()
I coded, but the fuction error occurred (0x8021100f).

    unsigned char bufConfig[0x36] = {};
    memset(&bufConfig[0x20], 0xff, 8);
    bufConfig[0x30] = 8;

    _sceUmdManWaitSema();
    res = _sceUmdExecGetConfigurationCmd(pUmdDrive, &bufConfig[0x30], &bufConfig[0x20]);
    _sceUmdManSignalSema();
    if (res < 0) {
        OutputPspError("_sceUmdExecGetConfigurationCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecGetConfigurationCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufConfig, sizeof(bufConfig));
        sceIoClose(uid);
    }

sceUmdExecReadDiscInfoCmd()
Also 0x8021100f error occurred.

    unsigned char bufDiscInfo[0x2c] = {};
    memset(&bufDiscInfo[0x20], 0xff, 12);

    _sceUmdManWaitSema();
    res = _sceUmdExecReadDiscInfoCmd(pUmdDrive, 12, &bufDiscInfo[0x20]);
    _sceUmdManSignalSema();
    if (res < 0) {
        OutputPspError("_sceUmdExecReadDiscInfoCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecReadDiscInfoCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufDiscInfo, sizeof(bufDiscInfo));
        sceIoClose(uid);
    }

47

(52 replies, posted in General discussion)

Edness wrote:

I know you've already confirmed the multi-partition UMD GAME+MOVIE discs are most likely correct size in your original post, but out of curiosity if you have any on hand, could you provide the PFI for one of those too?

Stealth feat. WipEout Pure Stealth Edition http://redump.org/disc/57052/

 00 00 00 00 00 00 00 00 12 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 16 00 00 80 00 31 E0 00 03 00 00 00 FC D3 3F
 00 09 C0 BF 00 03

Edness wrote:

Anyway: sceUmdExecGetConfigurationCmd() - Sends the expected command 0x46

Edness wrote:

Lastly: sceUmdExecReadDiscInfoCmd() - Sends the expected command 0x51

Thanks research. I'll code and test in the near future.

Edness wrote:

Random side note:

Thanks to you I know SysclibForKernel_NID().

48

(3,493 replies, posted in General discussion)

Kyaerosaber wrote:

Logs for DiscImageCreator_test dump of Ys Book I & II (USA) [TurboDuo]:

"Sub Indexes" tracks/cue are created. I think it's no problem.

49

(52 replies, posted in General discussion)

I tried "bufStruct[9] = 8" (0x800). Function call succeed, but hardware hanged up.
And tried "bufStruct[9] = 16" (0x1000). Function call failed.

By the way, if possible, could you research sceUmdExecReadDiscInfoCmd and sceUmdExecGetConfigurationCmd? Both are also SCSI-like fuctions.

50

(52 replies, posted in General discussion)

Changed to 16.

bufStruct[8] = 16;

The result is same as you expected. Disc is Dissidia 012.

 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 10 00 00 80 00 31 E0 00 03 00 00 00 FC AB 2F
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

EDIT:
PFI of DVD is 2048 bytes. According to Ecma-365, it's the same for UMD, but byte 19 - 2047 of UMD are all zeros. That is why dumping 18 bytes is sufficient for preservation.