That should be correct. If you see Existing attachment #1 on the left, it has been uploaded and attached to your post. "File has never been downloaded" just means exactly that - you haven't published the post, so no one else (usually moderators) have had a chance to download the logs for processing and adding your submission. The size limit for attachments is 2 or 3 MB.
1 2024-01-18 11:09:26
Re: Cannot add attachments to my posts ("File has never been downloaded") (5 replies, posted in General discussion)
2 2024-01-17 09:16:30
Re: question before account request and submission (4 replies, posted in Guests & account requests)
The better reads are mostly a general note, as some earlier drives tend to break down quickly due to manufacturing defects. I myself have a PX-716A that I've been using for CD submissions for a couple years now, largely without issues.
And Linux DiscImageCreator/Redumper is accepted, of course, I've also used it myself before for submissions. It just won't have an automatically pre-made submission info text file, which is done by MPF. And even then, MPF.Check can be used to generate them afterward, although it only works with DiscImageCreator logs, not Redumper.
3 2024-01-12 08:56:26
Re: A discussion on flags, regions, and languages (11 replies, posted in General discussion)
I can't really speak much for 1) and 2), it can be better answered by someone else, but the general rule of thumb is to usually just set the region to where your particular disc came from. If you bought it in the US, you set the region to that as well, however regions are also much more generalized for anything that isn't PC, e.g. USA region being the default for anything North America. When verifications from other regions come in, the region can be adjusted with their submissions. But as earlier - not really my place to speak on. Anyway:
3) You can mention it in the comments, but this actually applies to pretty much every PS2 (and PS1 for that matter) game disc pressed on a CD after 2007/2008. See [PS2] Casper and the Ghostly Trio (Europe) (En,Pt,Sv,No,Da,Fi,Pl) as an example - the disc I've dumped has the blue tinted back, but RetroGamer's disc had a silver/untinted data side. However I wouldn't say it's a super important note.
4) Typing <tab> will convert them to tabs in !submissioninfo.txt. I also had the same idea as you long ago to just use three spaces out of convenience, however, while tabs are converted to three spaces on both the forum and the entry pages, I was eventually informed that they were actually trimmed down to just one space when using the New Disc submission form, so using actual tabs is a must in that regard. I suppose you could probably skip converting them to tabs for submissions that will go on the verifications forum.
4 2023-12-14 21:56:28
Re: PS3 MIA Game Query (3 replies, posted in Guests & account requests)
No, this is separate release published in Latin America where both titles are bundled on the same disc, as indicated by the different serial, different mastering code, PVD date, larger size than both discs (PIC data also confirms the size is correct), and of course the "Combo Disc" in the title itself.
https://vgcollect.com/item/182494
If anything, the region just needs to be fixed on the database to not say USA, but that's about it.
---
The single disc US releases are already available on Redump as well:
[PS3] Sports Champions (USA) (En,Fr,Es,Pt) (FW3.40)
[PS3] Sports Champions (USA) (En,Fr,Es,Pt) (FW3.50)
[PS3] Medieval Moves - Deadmund's Quest (USA) (En,Fr,Es,Pt)
5 2023-11-27 01:12:56
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
I think there have actually been two different Linux versions made heh, but regardless - here's the updated version of the variant Jason098, Lazerdude and I use.
Tested my Plextor drive while I checking if the updated script works under Linux, even though it is on the spreadsheet already.
6 2023-11-21 14:51:12
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
Three more drives from the one and only:
7 2023-11-20 18:19:14
Re: A small spelling correction & question (3 replies, posted in Guests & account requests)
There was a lengthy discussion at the end of last year about standardizing the capitalization of prepositions and the like, and the general consensus was to use the Wikipedia style - them being capitalized only if they're 5 or more letters long. If you search up other titles, you'll see the word "over" isn't capitalized anywhere:
Aces over Europe
Crash: Mind over Mutant
Secret Weapons over Normandy
And the serial field is written exactly as-is only on the disc itself. You can't expect a dumper to always have the cover, but they'll definitely have the disc if they have something to submit. The spine serial, if it is different, can be added to the comments, however.
Asian Sony discs almost never have the hyphen, and European Sony discs almost always have it. Don't have much experience with North American Sony discs personally to know which one is more commonly printed.
(Some minor exceptions also exist, mostly with development discs that don't have any serial printed, so the internal serial is sometimes used instead etc. etc., even though this would be technically against the guidelines.)
8 2023-11-09 21:43:01
Re: Audio CD ripping question (2 replies, posted in General discussion)
Audio-CD (as well as DVD-Video, BD-Video, and newer systems like PS4 and PS5) are hidden from the public. Submit a disc or two to get the Dumper status, and you'll get access to those sections.
9 2023-10-31 13:34:27
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
And 10 more drives!
10 2023-10-30 10:04:45
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
12 more drives incoming! I threw in my SH-D162D flashed with Kreon firmware as well just for kicks - don't know if it's also acceptable here, but the rest are new additions regardless.
11 2023-10-13 15:35:00
Re: Access to Old Redump DAT Files (7 replies, posted in General discussion)
Various revisions can also be found on web.archive.org if that helps. For March 2023, it has two versions:
12 2023-10-12 11:16:00
Re: UmdImageCreator (52 replies, posted in General discussion)
Nice, works well for me so far.
13 2023-10-07 13:29:48
Re: UmdImageCreator (52 replies, posted in General discussion)
I'm not sure, your guess is as good as mine. It could be one of the 0xF0 commands, or it could be something completely different.
Another note, I noticed the SCSI command whitelist in older FW revisions normally has 3 x int32 values per element, the 3rd one always seemingly being null. However FW 1.50 actually uses that 3rd value as a pointer to a string with the original command name. (In newer FW like 6.60 the array is 2x int8.) The command names for 0x00-0xC0 are pretty standard besides DVD->UMD replacements, but the 0xF0 command names without any associated function/NID could be useful too.
{0x00, 0x01}, // TEST_UNIT_READY
{0x03, 0x02}, // REQUEST_SENSE
{0x12, 0x02}, // INQUIRY
{0x1B, 0x01}, // START_STOP_UNIT
{0x1E, 0x01}, // PREVENT_ALLOW_MEDIA
{0x23, 0x02}, // READ_FORMAT_CAPACITIES
{0x25, 0x02}, // READ_UMD_CAPACITY
{0x28, 0x08}, // READ10
{0x2B, 0x01}, // SEEK
{0x34, 0x01}, // PREFETCH10
{0x46, 0x02}, // GET_CONFIGURATION
{0x4A, 0x02}, // GET_STAT_EVENT
{0x55, 0x04}, // MODE_SELECT10
{0x5A, 0x02}, // MODE_SENSE10
{0xAD, 0x02}, // READ_UMD_STRUCTURE
{0xB6, 0x04}, // SET_STREAMING
{0xBB, 0x01}, // SET_SPEED
{0xBD, 0x02}, // MECHANISM_STATUS
{0xF0, 0x02}, // DETECT_UMD_PSP
{0xF1, 0x08}, // READ_UMD_MKI
{0xF2, 0x02}, // REPORT_CACHE
{0xF3, 0x01}, // CLEAR_CACHE_INFO
{0xF4, 0x02}, // GET_MEDIA_INFO
{0xF5, 0x02}, // TEST
{0xF6, 0x01}, // SET_ACCESS_LIMIT
{0xF7, 0x01}, // SET_LOCK_LENGTH
{0xF8, 0x01}, // SET_AREA_LIMIT
{0xF9, 0x02}, // GET_ERROR_LOG
{0xFA, 0x02}, // TEST_PI
{0xFB, 0x04}, // TEST_PO
{0xFC, 0x02}, // GET_ADJUST_DATA
{0xFD, 0x04}, // SET_ADJUST_DATA14 2023-10-06 16:04:29
Re: UmdImageCreator (52 replies, posted in General discussion)
sarami wrote:
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?
Possible.
Another guess I have could be it's some form of Disc ID - Sony already has a unique ID for every disc on PS2 and PS3. (If not from the MKI command, maybe from another one.)
On PS2 the (DNAS) Disc ID is also 5 bytes long. And while currently on Redump only the first two bytes are removed due to being serialized/random, from my observations I'm pretty sure it's supposed to be the first three bytes (see [PS2] Burnout Revenge (Europe, Australia) (En,Fr,De) as an example) followed by the region on the 4th byte (0x20 = Asia, 0x30 = USA, 0x40 = Europe etc.), making it 16.7 million unique Disc IDs for each game on PS2.
Likewise, PS3's Disc ID being 16 bytes long, the last 4 bytes are also removed for each entry, also followed by the region on the 5th byte (0x01 = Asia, 0x03 = USA, 0x04 = Europe etc.), making it theoretically 4.2 billion unique IDs per game.
With this in mind, I wouldn't be surprised if Sony also had some form of unique Disc ID for PSP, too. Although wouldn't the 0x08 written at buf[2] interfere with it?
15 2023-10-05 16:31:33
Re: UmdImageCreator (52 replies, posted in General discussion)
Hmm, can you memcpy the 0x4000 or 0x8000 bytes of data back from the SPKGetMKI address? It likely wrote something there and left the buffer for the function arg alone. 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.
For good measure maybe also copy the data from the MKI address before memset'ing it to 00, to see if there's already something there.
16 2023-10-05 14:59:47
Re: UmdImageCreator (52 replies, posted in General discussion)
sarami wrote:
void* p = _sceUmdManSPKGetMKI();p is 0x880f1240
Looks like that is in kernel module address space 0x88000000-0x8837FFFF, per documentation.
This does make more sense than just plain 0x1C0, but now part of me wonders if this is a valid region of data that can be overwritten, or if this is just the offset of the module itself, indicating its base is at 0x880F1080. 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 
Also, at first I couldn't find any mention of this MKI thing anywhere on the internet, but I just now stumbled upon an archived thread that mentions "UMD MKI" once. Doesn't say what it stands for, but it's something.
17 2023-10-05 10:59:02
Re: UmdImageCreator (52 replies, posted in General discussion)
I think the address has to be 0x1C0, it seems to be firmware hardcoded. sceUmdExecReadMKICmd() (and also sceUmdExecRead10Cmd()) both call a subroutine which contains a function named sceUmdManSPKGetMKI() - this always returns 0x1C0. And after that, it calls another d-cache function sceKernelDcacheWritebackInvalidateRange(0x1C0, 0x4000), arg0 coming from SPKGetMKI, and arg1 coming from 8 << 11, the 8 coming from ReadMKI's arg2.
Without a debugger to see what exactly it's doing, it's hard to know if those addresses are relocated by the system or not. However, could you try calling sceUmdManSPKGetMKI() on its own and print out what address it returns? Maybe this will give an answer whether you truly have to put 0x1C0 or not. (And you could likely use the output of that to set up the ReadMKI call.)
----------
This is unrelated, but I did a bit more research about the SCSI commands that umdman.prx has functions for. Some firmware revisions have functions that send the commands 0xA3 and 0xA4, but neither of them have any NIDs associated. And today I noticed what looks to be an array of whitelisted commands it can send. In addition to the FW NID map function I wrote a few replies back, it looks like it would allow commands 0x00, 0x23, 0x25, 0xA3, 0xA4, 0xB6, 0xBB, and vendor specific commands 0xF5, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD. None of these also have a specific NID-hashed function.
However, sceUmdExecReadCapacityCmd() seems to be the only function that allows putting your own command as arg0, followed by the UMD drive as arg1 of course. While I assume this is where you would normally put 0x23/0x25, I wonder if it would be possible to exploit and take advantage of this function to send other commands. Though there is no function that calls it in any firmware it looks like (checked 1.50, 3.52, 6.60), so knowing that it wants for arg2 and arg3 will need guesswork.
I've edited the 3.70-6.60 NID map to also include this function commented with "Any?"
18 2023-10-04 11:23:04
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
Here's 11 more drives. One seems to be a duplicate on the spreadsheet, and another didn't return anything from any command.
(There also seem to be a few others at the end of Page 1 that were missed, FYI)
19 2023-10-03 16:33:58
Re: UmdImageCreator (52 replies, posted in General discussion)
The ReadMKI function itself seems pretty large, and the preceding functions that call it are a bit all over the place too. It seems to take values from 2 functions above, the 1st of which calls the lower function that contains the ReadMKI call with (UMD drive, 0, 8, 0)
A 5 byte buffer is created on the stack, arg1 and arg2 being stored as int16s at 0x00 and 0x02, and arg3 as an int8 to 0x04.
If I am reading it correctly, you can just write 0x08 at buffer[0x2] and that's it.
sceUmdExecReadMKICmd() is called with 4 arguments:
$a0 - UMD drive (as always)
$a1 - Pointer to the buffer
$a2 - Number 8 (from buffer[0x2])
$a3 - Number 448 (0x1C0)
Overall, I would say this is it, if it weren't for some unusual calls between the buffer creation and the actual ReadMKI call. It calls memset(0x1C0, 0x00, 0x8000) - I'm not sure if 0x1C0 a valid address.
And right after that, it calls sceKernelDcacheInvalidateRange(0x1C0, 0x4000), (the 2nd arg being 8 (from arg2) << 11 = 0x4000), implying the address 0x1C0 is somewhere in the CPU data cache region? No idea.
Does that also mean it expects you to get the output back from d-cache too?
20 2023-10-02 23:54:31
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
Yeah, I thought that was pretty unusual as well. Perhaps another field is needed, denoting the exact "full" drive model/type that sits between the vendor and model names. Or maybe just including that as part of the model name. I dunno.
21 2023-10-02 20:00:03
Re: UmdImageCreator (52 replies, posted in General discussion)
Yeah, I already read about the 128-bit addition for NID randomizing before, 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? Since the SCSI command is known to be 0xAD, it should be possible to search backwards.
I just wrote a proof of concept script that can do exactly that
Edit 1: Just scanned and retrieved all ReadUMDStructure NIDs from firmwares 3.70-6.61 out of interest. This likely can work for other SCSI-like functions here too. But now the bigger question is - is it possible to easily get the current firmware number via software, or is that also behind a NID hashed function? (If it is possible, what format does it normally return? BCD? String?)
Edit 2: Well, I generated something. I can at least confirm the accuracy of my script for <3.70 and 6.60, so anything in-between is (probably) correct too. sceUmdExecReqSenseCmd() and sceUmdExecInquiryCmd() seem to actually never change their NIDs on any firmware, and always remain as 0x2CBE959B and 0x1B19A313 respectively. sceUmdManGetUmdDrive() also seems to always remain as 0x47E2B6D8.
If this is of any use to you - great! If not - it was a fun experiment for me, at least. Do note that not every function exists in every firmware revision, but I did confirm the asm portion of all these firmware revision groups are identical. Seems like the NIDs only change if the asm is different - could be the random 128-bit addition is some form of a hash of the asm data. (Unlikely)
// the PRX modules store each FW digit as its own byte
// e.g. FW 3.71 = 0x03070110 at 0x010F50 in umdman.prx
// so here it's converted to a short BCD value, 0x371
// fw >> 8 & 0xF | fw >> 12 & 0xF0 | fw >> 16 & 0xF00
short firmware = 0x660;
unsigned int sceUmdExecReqSenseCmd = 0x2CBE959B; // 0x03
unsigned int sceUmdExecInquiryCmd = 0x1B19A313; // 0x12
unsigned int sceUmdExecStartStopUnitCmd = 0; // 0x1B
unsigned int sceUmdExecPreventAllowMediaCmd = 0; // 0x1E
unsigned int sceUmdExecRead10Cmd = 0; // 0x28
unsigned int sceUmdExecSeekCmd = 0; // 0x2B
unsigned int sceUmdExecPrefetch10Cmd = 0; // 0x34
unsigned int sceUmdExecGetConfigurationCmd = 0; // 0x46
unsigned int sceUmdExecGetEventStatusCmd = 0; // 0x4A
unsigned int sceUmdExecReadDiscInfoCmd = 0; // 0x51
unsigned int sceUmdExecModSelectCmd = 0; // 0x55
unsigned int sceUmdExecModSenseCmd = 0; // 0x5A
unsigned int sceUmdExecReadUMDStructureCmd = 0; // 0xAD
unsigned int sceUmdExecMechaStatCmd = 0; // 0xBD
unsigned int sceUmdExecAllocateFromReadCmd = 0; // 0xF0
unsigned int sceUmdExecReadMKICmd = 0; // 0xF1
unsigned int sceUmdExecReportCacheCmd = 0; // 0xF2
unsigned int sceUmdExecClearCacheInfoCmd = 0; // 0xF3
unsigned int sceUmdExecGetMediaInfoCmd = 0; // 0xF4
unsigned int sceUmdExecSetAccessLimitCmd = 0; // 0xF6
unsigned int sceUmdExecSetLockLengthCmd = 0; // 0xF7
unsigned int sceUmdExecSetAreaLimitCmd = 0; // 0xF8
unsigned int sceUmdExecReadCapacityCmd = 0; // Any?
if (firmware < 0x370) {
// FW 1.00 - 3.60
sceUmdExecStartStopUnitCmd = 0xE3F448E0; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0x2A08FE9A; // 0x1E
sceUmdExecRead10Cmd = 0x1B1BF9FD; // 0x28
sceUmdExecSeekCmd = 0x250E6975; // 0x2B
sceUmdExecPrefetch10Cmd = 0x18DE1880; // 0x34
sceUmdExecGetConfigurationCmd = 0xC25D7212; // 0x46
sceUmdExecGetEventStatusCmd = 0x65E1B97E; // 0x4A
sceUmdExecReadDiscInfoCmd = 0xD7A2F4A2; // 0x51
sceUmdExecModSelectCmd = 0xCEE55E3E; // 0x55
sceUmdExecModSenseCmd = 0x2A39569B; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x3D44BABF; // 0xAD
sceUmdExecMechaStatCmd = 0xE5B7EDC5; // 0xBD
sceUmdExecAllocateFromReadCmd = 0x68577709; // 0xF0
sceUmdExecReadMKICmd = 0xF819E17C; // 0xF1
sceUmdExecReportCacheCmd = 0x98345381; // 0xF2
sceUmdExecClearCacheInfoCmd = 0x73E49F8F; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x108B2322; // 0xF4
sceUmdExecSetAccessLimitCmd = 0x7094E3A7; // 0xF6
sceUmdExecSetLockLengthCmd = 0xD31DAD7E; // 0xF7
sceUmdExecSetAreaLimitCmd = 0x61C32A52; // 0xF8
sceUmdExecReadCapacityCmd = 0x5AA96415; // Any?
}
else if (firmware < 0x380) {
// FW 3.70, 3.71, 3.72, 3.73
sceUmdExecStartStopUnitCmd = 0xD4132E08; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0xB629961F; // 0x1E
sceUmdExecRead10Cmd = 0x9E7564BC; // 0x28
sceUmdExecSeekCmd = 0xE8A768B5; // 0x2B
sceUmdExecPrefetch10Cmd = 0x9E722740; // 0x34
sceUmdExecGetConfigurationCmd = 0x607BF8CA; // 0x46
sceUmdExecGetEventStatusCmd = 0x84F3759A; // 0x4A
sceUmdExecReadDiscInfoCmd = 0x466839B7; // 0x51
sceUmdExecModSelectCmd = 0xDDB308E9; // 0x55
sceUmdExecModSenseCmd = 0x200810E8; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x3D94D00C; // 0xAD
sceUmdExecMechaStatCmd = 0x6CEDA538; // 0xBD
sceUmdExecAllocateFromReadCmd = 0x9EE39B6A; // 0xF0
sceUmdExecReadMKICmd = 0xB157769B; // 0xF1
sceUmdExecReportCacheCmd = 0x9D9848F2; // 0xF2
sceUmdExecClearCacheInfoCmd = 0x0933B6FB; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x92E6E273; // 0xF4
sceUmdExecSetAccessLimitCmd = 0xD5CC2085; // 0xF6
sceUmdExecSetLockLengthCmd = 0xB865CC4C; // 0xF7
sceUmdExecSetAreaLimitCmd = 0x928C1752; // 0xF8
sceUmdExecReadCapacityCmd = 0x5CD9ACF5; // Any?
}
else if (firmware < 0x395) {
// FW 3.80, 3.90, 3.93
sceUmdExecStartStopUnitCmd = 0x62506AA0; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0x1B70C53F; // 0x1E
sceUmdExecRead10Cmd = 0x33072B62; // 0x28
sceUmdExecSeekCmd = 0x818506C1; // 0x2B
sceUmdExecPrefetch10Cmd = 0x8AF305CC; // 0x34
sceUmdExecGetConfigurationCmd = 0x3809B921; // 0x46
sceUmdExecGetEventStatusCmd = 0x5F37BD96; // 0x4A
sceUmdExecReadDiscInfoCmd = 0x3BF9BE3E; // 0x51
sceUmdExecModSelectCmd = 0xB6BCF945; // 0x55
sceUmdExecModSenseCmd = 0x05CF9760; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x2A12BF44; // 0xAD
sceUmdExecMechaStatCmd = 0xD1FFD521; // 0xBD
sceUmdExecAllocateFromReadCmd = 0xCEBDE68B; // 0xF0
sceUmdExecReadMKICmd = 0x350EEA2B; // 0xF1
sceUmdExecReportCacheCmd = 0xE7D62A27; // 0xF2
sceUmdExecClearCacheInfoCmd = 0xECAF10D9; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x81C55E67; // 0xF4
sceUmdExecSetAccessLimitCmd = 0x90746ECA; // 0xF6
sceUmdExecSetLockLengthCmd = 0xC945EE7E; // 0xF7
sceUmdExecSetAreaLimitCmd = 0xB9A0113D; // 0xF8
sceUmdExecReadCapacityCmd = 0x62473046; // Any?
}
else if (firmware < 0x420) {
// FW 3.95, 3.96, 4.00, 4.01, 4.05
sceUmdExecStartStopUnitCmd = 0x57436030; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0x9DAD4CC0; // 0x1E
sceUmdExecRead10Cmd = 0x74F29ED7; // 0x28
sceUmdExecSeekCmd = 0x14EAAA28; // 0x2B
sceUmdExecPrefetch10Cmd = 0x9ABD6DE1; // 0x34
sceUmdExecGetConfigurationCmd = 0xFE0D2641; // 0x46
sceUmdExecGetEventStatusCmd = 0xF8912660; // 0x4A
sceUmdExecReadDiscInfoCmd = 0x67D4D414; // 0x51
sceUmdExecModSelectCmd = 0xE90AEA97; // 0x55
sceUmdExecModSenseCmd = 0xCA2EA0FF; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x12BA4DDE; // 0xAD
sceUmdExecMechaStatCmd = 0x0925EE00; // 0xBD
sceUmdExecAllocateFromReadCmd = 0xD01B4969; // 0xF0
sceUmdExecReadMKICmd = 0x43FD7090; // 0xF1
sceUmdExecReportCacheCmd = 0x529635A7; // 0xF2
sceUmdExecClearCacheInfoCmd = 0x01B1AA7E; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x4461C19E; // 0xF4
sceUmdExecSetAccessLimitCmd = 0x3E6B9E50; // 0xF6
sceUmdExecSetLockLengthCmd = 0xADA614C2; // 0xF7
sceUmdExecSetAreaLimitCmd = 0x376BFD4F; // 0xF8
sceUmdExecReadCapacityCmd = 0x965D8417; // Any?
}
else if (firmware < 0x500) {
// FW 4.20, 4.21
sceUmdExecStartStopUnitCmd = 0x0EE48C15; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0xBDE7298B; // 0x1E
sceUmdExecRead10Cmd = 0xEC3FDCEF; // 0x28
sceUmdExecSeekCmd = 0x9E2FB7DF; // 0x2B
sceUmdExecPrefetch10Cmd = 0x4F2B52DC; // 0x34
sceUmdExecGetConfigurationCmd = 0x251AD684; // 0x46
sceUmdExecGetEventStatusCmd = 0xA17129C2; // 0x4A
sceUmdExecReadDiscInfoCmd = 0xB7CE4D74; // 0x51
sceUmdExecModSelectCmd = 0x2E730DEF; // 0x55
sceUmdExecModSenseCmd = 0x9430AFEF; // 0x5A
sceUmdExecReadUMDStructureCmd = 0xE006F0E9; // 0xAD
sceUmdExecMechaStatCmd = 0xBE559B33; // 0xBD
sceUmdExecAllocateFromReadCmd = 0x7A2B484B; // 0xF0
sceUmdExecReadMKICmd = 0xF9BBA21C; // 0xF1
sceUmdExecReportCacheCmd = 0x05FE3D00; // 0xF2
sceUmdExecClearCacheInfoCmd = 0xB88C1DF1; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x361B88FE; // 0xF4
sceUmdExecSetAccessLimitCmd = 0xCDB02062; // 0xF6
sceUmdExecSetLockLengthCmd = 0x1BDFD70C; // 0xF7
sceUmdExecSetAreaLimitCmd = 0x531937DB; // 0xF8
sceUmdExecReadCapacityCmd = 0xB24480CB; // Any?
}
else if (firmware < 0x570) {
// FW 5.00, 5.01, 5.02, 5.03, 5.05, 5.50, 5.51, 5.55
sceUmdExecStartStopUnitCmd = 0x1B2B8759; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0x66B4CC78; // 0x1E
sceUmdExecRead10Cmd = 0x98D75CC0; // 0x28
sceUmdExecSeekCmd = 0xAEC4DA2C; // 0x2B
sceUmdExecPrefetch10Cmd = 0x1BE0124C; // 0x34
sceUmdExecGetConfigurationCmd = 0x19BCD653; // 0x46
sceUmdExecGetEventStatusCmd = 0xF2B1A490; // 0x4A
sceUmdExecReadDiscInfoCmd = 0xBD102376; // 0x51
sceUmdExecModSelectCmd = 0x9FC2FD97; // 0x55
sceUmdExecModSenseCmd = 0x585F1728; // 0x5A
sceUmdExecReadUMDStructureCmd = 0xD4E51A75; // 0xAD
sceUmdExecMechaStatCmd = 0x8BDE7034; // 0xBD
sceUmdExecAllocateFromReadCmd = 0x32D89DA4; // 0xF0
sceUmdExecReadMKICmd = 0xF9C66D4A; // 0xF1
sceUmdExecReportCacheCmd = 0x7065FD6E; // 0xF2
sceUmdExecClearCacheInfoCmd = 0x1F0338FE; // 0xF3
sceUmdExecGetMediaInfoCmd = 0xBDF4842D; // 0xF4
sceUmdExecSetAccessLimitCmd = 0xFCA1A098; // 0xF6
sceUmdExecSetLockLengthCmd = 0xC7D14FBE; // 0xF7
sceUmdExecSetAreaLimitCmd = 0x16588BAA; // 0xF8
sceUmdExecReadCapacityCmd = 0xDD017FFE; // Any?
}
else if (firmware < 0x600) {
// FW 5.70
sceUmdExecStartStopUnitCmd = 0x89AA72CD; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0xB6BE48A4; // 0x1E
sceUmdExecRead10Cmd = 0x6C0C6E60; // 0x28
sceUmdExecSeekCmd = 0x8AAE6940; // 0x2B
sceUmdExecPrefetch10Cmd = 0xB7089372; // 0x34
sceUmdExecGetConfigurationCmd = 0x62212597; // 0x46
sceUmdExecGetEventStatusCmd = 0x5361EBAF; // 0x4A
sceUmdExecReadDiscInfoCmd = 0xF4B80F3C; // 0x51
sceUmdExecModSelectCmd = 0xFA124BD3; // 0x55
sceUmdExecModSenseCmd = 0xA50AD929; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x0D3372E8; // 0xAD
sceUmdExecMechaStatCmd = 0x8322DB90; // 0xBD
sceUmdExecAllocateFromReadCmd = 0xE2234907; // 0xF0
sceUmdExecReadMKICmd = 0x2DC746B5; // 0xF1
sceUmdExecReportCacheCmd = 0xE590AD02; // 0xF2
sceUmdExecClearCacheInfoCmd = 0x3C0ACB0D; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x468AC548; // 0xF4
sceUmdExecSetAccessLimitCmd = 0xA78D71C3; // 0xF6
sceUmdExecSetLockLengthCmd = 0x6236483E; // 0xF7
sceUmdExecSetAreaLimitCmd = 0x57BD4866; // 0xF8
sceUmdExecReadCapacityCmd = 0xBBEA87FB; // Any?
}
else if (firmware < 0x630) {
// FW 6.00, 6.10, 6.20
sceUmdExecStartStopUnitCmd = 0x5CF0DFAC; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0xCDA8E394; // 0x1E
sceUmdExecRead10Cmd = 0x319C9905; // 0x28
sceUmdExecSeekCmd = 0x849A4325; // 0x2B
sceUmdExecPrefetch10Cmd = 0x65FD0561; // 0x34
sceUmdExecGetEventStatusCmd = 0x48D85CEE; // 0x4A
sceUmdExecReadDiscInfoCmd = 0xB87FA807; // 0x51
sceUmdExecModSelectCmd = 0x6B92F9E8; // 0x55
sceUmdExecModSenseCmd = 0x57E17255; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x806D66A7; // 0xAD
sceUmdExecAllocateFromReadCmd = 0xC54D7B8F; // 0xF0
sceUmdExecReadMKICmd = 0xD047DEBC; // 0xF1
sceUmdExecClearCacheInfoCmd = 0x04E5EFFA; // 0xF3
sceUmdExecGetMediaInfoCmd = 0xE2BAAD9C; // 0xF4
sceUmdExecSetLockLengthCmd = 0xBFDA8AC7; // 0xF7
sceUmdExecReadCapacityCmd = 0x2B79C006; // Any?
}
else if (firmware < 0x650) {
// FW 6.30, 6.31, 6.35, 6.36, 6.37, 6.38, 6.39
sceUmdExecStartStopUnitCmd = 0x7B9C43C9; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0xC9509423; // 0x1E
sceUmdExecRead10Cmd = 0x5B0F6FC6; // 0x28
sceUmdExecSeekCmd = 0x64AEDFB3; // 0x2B
sceUmdExecPrefetch10Cmd = 0xAE3F99E2; // 0x34
sceUmdExecGetEventStatusCmd = 0x5D7C8F9E; // 0x4A
sceUmdExecReadDiscInfoCmd = 0x717EF202; // 0x51
sceUmdExecModSelectCmd = 0x047BCEA0; // 0x55
sceUmdExecModSenseCmd = 0x03DE43F5; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x05C33243; // 0xAD
sceUmdExecAllocateFromReadCmd = 0xC447F257; // 0xF0
sceUmdExecReadMKICmd = 0x01EA806F; // 0xF1
sceUmdExecClearCacheInfoCmd = 0x87070DC7; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x8F628DAF; // 0xF4
sceUmdExecSetLockLengthCmd = 0xFC40080F; // 0xF7
sceUmdExecReadCapacityCmd = 0x5802953B; // Any?
}
//else if (firmware < 0x660) {} // FW 6.50 (UNRELEASED)
else {
// FW 6.60, 6.61
sceUmdExecStartStopUnitCmd = 0x5219AF31; // 0x1B
sceUmdExecPreventAllowMediaCmd = 0x5AC94A3C; // 0x1E
sceUmdExecRead10Cmd = 0xE3716915; // 0x28
sceUmdExecSeekCmd = 0xB01F65CE; // 0x2B
sceUmdExecPrefetch10Cmd = 0xC615D6C9; // 0x34
sceUmdExecGetEventStatusCmd = 0xBD974D70; // 0x4A
sceUmdExecReadDiscInfoCmd = 0xF861E69B; // 0x51
sceUmdExecModSelectCmd = 0x2C5F9A65; // 0x55
sceUmdExecModSenseCmd = 0xEB0841CE; // 0x5A
sceUmdExecReadUMDStructureCmd = 0x406E8F99; // 0xAD
sceUmdExecAllocateFromReadCmd = 0x8DA33BBD; // 0xF0
sceUmdExecReadMKICmd = 0x6D17FD57; // 0xF1
sceUmdExecClearCacheInfoCmd = 0x77E81350; // 0xF3
sceUmdExecGetMediaInfoCmd = 0x27C1869A; // 0xF4
sceUmdExecSetLockLengthCmd = 0xEEBF3121; // 0xF7
sceUmdExecReadCapacityCmd = 0xCC40BED8; // Any?
}22 2023-10-02 19:01:19
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
ehw wrote:
I'm not sure whether to trust when the left most byte is different because other bytes within the page might be altered randomly from different runs too. I'm making notes of when this happens in the notes field but I'm looking for when the first 4 bytes are exactly 00 03 00 00 to know that it's workable for sure.
Fair enough, the point I was trying to make was, it may be a good idea to ask the dumper to try again with a different disc, since in his case this only occurred with one specific PC game disc.
Anyway, 6 more drives from me and a few friends, sorted in folders with which disc was used and all. The _pylinux folder contains the modified version for Linux that jason098 and I did. smartctl was used to get some drive info, so I ended up making it a part of the script. So, some folders will have a smartctl.txt file with that info separately from an earlier version, and others will have that info included in logfile.log.
23 2023-10-02 11:47:33
Re: UmdImageCreator (52 replies, posted in General discussion)
Nice. Out of curiosity, is the PFI data dumping currently only limited to FW 3.52 (or rather any FW below 3.70 where NIDs weren't randomized?) Because eventually I would like to dump that data from my UMDs too just for safekeeping. (Although since the disc format info is now known, I could just fake generate it myself...)
If that's the case, is knowing the NID enough to make it possible on newer firmwares? This did motivate me to look into a bit deeper in how PSP FW stuff works. For example, in FW 6.60 and 6.61, sceUmdExecReadUMDStructureCmd() should use the NID 0x406E8F99 if my understanding is correct.
Otherwise, if it was possible to do on any FW regardless, or if it needs more than just the NID, then ignore the above, haha.
24 2023-10-02 09:00:45
Re: UmdImageCreator (52 replies, posted in General discussion)
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.
I noticed there's sceUmdExecReadUMDStructureCmd() here too, and here it actually does set the write size at 0x08 of the buffer to 0x800, which makes it kinda interesting that it crashed when you tried that size. Although here it doesn't create the 2nd buffer on the stack, it seems to be likely pre-allocated in another function that would call this one with a pointer to it, but the preceding function doesn't exist anymore in FW 3.52.
25 2023-10-01 22:28:24
Re: Dumping DVDs RAW - An ongoing investigation (we need your help!) (57 replies, posted in General discussion)
Tested another drive I had laying around, as well as sent this in a chat with a couple of friends who were also interested in it, so there may be more to send soon. The laptop HP SU-208CB drive I just tested here I'm like 99.1% sure is actually a rebranded TSSTcorp drive, so make of that what you will for which brand to put that under. I also have a few more to test, those being an assortment of drives in other old PCs but that's for later.
It seemed to completely hang when it got to F1 05. I couldn't kill the process or anything, so I ended up force shutting it down after like an hour which means it didn't flush anything to the log file either. But 3C 02 00 got 0x8BC bytes of raw sector data, at least. I re-ran just the beginning to get the basic drive info at least, but I don't feel like running the whole thing on that crappy laptop again, as it was excruciatingly slow.
Jason098 from the aforementioned group chat modified it slightly to run on Linux since almost everyone in my friend group uses it, which also means the get_dvd_drive_info() function had to be commented out for them.
There's also an odd edge case to consider: one of Jason's discs had "unexpected" data in the 1st byte of the PSN. AFAIK, normally (if the PFI is anything to go by) the leftmost byte is unused so usually it's just 0x00, but that one disc had "random" values in there like 50030000, 20030001, etc. It may be better to mask out the 1st byte and only check if the lower 24 bits equal to and increment from 0x030000 instead. It's possible a field marked as "No" could actually be wrong and mislabelled due to this oddity.
There were some other drive issues he had too, like if the lower nybble of the 3C command ended with 0x0B, the drive would pretty much hang so we had to work around that as well (which I understand he also later brought up to you in another server.)