Search options (Page 3 of 57)

2023-12-16 15:38:12

Uploaded test version for Tages.
https://github.com/saramibreak/DiscImag … 1858835085

2023-12-15 17:32:41

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.

2023-12-13 17:32:07

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.

2023-12-12 08:54:34

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.

2023-12-12 05:52:37

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?

2023-12-11 16:49:58

Nemok wrote:

That's why I wanted to try "/r".

"/r" generates only the forward-image using backward reading.

I dumped Moto Racer 3 (USA) http://redump.org/disc/31578/ with /r. As a result, I found it that 329693 ... 329946 are different sectors. But Jackal says "Disc has 260 twin sectors in range 329687-329947".

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

2023-12-10 14:49:40

Nemok wrote:

- hashes (with duplicated sectors inserted into the disc image)

You dumped http://redump.org/disc/34669/ . How did you get the hashes with duplicated sectors inserted into the disc image?

2023-12-09 13:16:25

Nemok wrote:

The issue is fixed. Thanks sarami.

Thanks several testing.

Nemok wrote:

What is the current state of Tages support ?
The github page mentions that DIC "can read in reverse, but specifications are not decided".

I don't know how redump.org stipulates that twin sectors be preserved.

Nemok wrote:

The associated command seems to have been "/r" at one point, as found here: http://wiki.redump.org/index.php?title= … f_Commands, but is not recognized anymore.

Latest commands list is here. https://github.com/saramibreak/DiscImag … nd-options

2023-12-08 15:22:15

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

2023-12-07 14:48:47

Nemok wrote:

Same behavior unfortunately, though the error has changed a little :

I tried some mixed mode disc, but it's no problem. Could you upload the logs?

2023-12-07 06:29:10

Nemok wrote:

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

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

2023-12-06 14:54:54

Nemok wrote:

Also discovered today :

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

2023-12-05 04:16:26

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

2023-12-04 12:45:53

Nemok wrote:

Pack mode without /c2 is still broken.

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

2023-12-03 15:51:10

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

2023-12-01 15:40:40

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

2023-12-01 15:38:56

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

2023-10-12 03:28:03

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

2023-10-07 10:52:55

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?

2023-10-06 14:06:18

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?

2023-10-05 16:25:25

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].

2023-10-05 14:30:59

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.

2023-10-05 10:31:24

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);

2023-10-03 15:40:48

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???

2023-10-02 13:58:41

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.

Search options (Page 3 of 57)

Posts found: 51 to 75 of 1,410

51 Reply by sarami 2023-12-16 15:38:12

Re: DiscImageCreator (3,534 replies, posted in General discussion)

52 Reply by sarami 2023-12-15 17:32:41

Re: DiscImageCreator (3,534 replies, posted in General discussion)

53 Reply by sarami 2023-12-13 17:32:07

Re: DiscImageCreator (3,534 replies, posted in General discussion)

54 Reply by sarami 2023-12-12 08:54:34

Re: DiscImageCreator (3,534 replies, posted in General discussion)

55 Reply by sarami 2023-12-12 05:52:37

Re: DiscImageCreator (3,534 replies, posted in General discussion)

56 Reply by sarami 2023-12-11 16:49:58

Re: DiscImageCreator (3,534 replies, posted in General discussion)

57 Reply by sarami 2023-12-10 14:49:40

Re: DiscImageCreator (3,534 replies, posted in General discussion)

58 Reply by sarami 2023-12-09 13:16:25

Re: DiscImageCreator (3,534 replies, posted in General discussion)

59 Reply by sarami 2023-12-08 15:22:15

Re: DiscImageCreator (3,534 replies, posted in General discussion)

60 Reply by sarami 2023-12-07 14:48:47

Re: DiscImageCreator (3,534 replies, posted in General discussion)

61 Reply by sarami 2023-12-07 06:29:10

Re: DiscImageCreator (3,534 replies, posted in General discussion)

62 Reply by sarami 2023-12-06 14:54:54

Re: DiscImageCreator (3,534 replies, posted in General discussion)

63 Reply by sarami 2023-12-05 04:16:26

Re: DiscImageCreator (3,534 replies, posted in General discussion)

64 Reply by sarami 2023-12-04 12:45:53

Re: DiscImageCreator (3,534 replies, posted in General discussion)

65 Reply by sarami 2023-12-03 15:51:10

Re: DiscImageCreator (3,534 replies, posted in General discussion)

66 Reply by sarami 2023-12-01 15:40:40

Re: DiscImageCreator (3,534 replies, posted in General discussion)

67 Reply by sarami 2023-12-01 15:38:56

Re: UmdImageCreator (53 replies, posted in General discussion)

68 Reply by sarami 2023-10-12 03:28:03

Re: UmdImageCreator (53 replies, posted in General discussion)

69 Reply by sarami 2023-10-07 10:52:55

Re: UmdImageCreator (53 replies, posted in General discussion)

70 Reply by sarami 2023-10-06 14:06:18

Re: UmdImageCreator (53 replies, posted in General discussion)

71 Reply by sarami 2023-10-05 16:25:25

Re: UmdImageCreator (53 replies, posted in General discussion)

72 Reply by sarami 2023-10-05 14:30:59

Re: UmdImageCreator (53 replies, posted in General discussion)

73 Reply by sarami 2023-10-05 10:31:24

Re: UmdImageCreator (53 replies, posted in General discussion)

74 Reply by sarami 2023-10-03 15:40:48

Re: UmdImageCreator (53 replies, posted in General discussion)

75 Reply by sarami 2023-10-02 13:58:41

Re: UmdImageCreator (53 replies, posted in General discussion)

Posts found: 51 to 75 of 1,410